Bank, treasury och ISO 20022-konnektivitet
Betalningar ut, kontoutdrag in, avstämt automatiskt i alla valutor
Treasuryteam knappar fortfarande in betalningar på nytt och matchar kontoutdrag för hand
Många treasuryteam knappar in betalningar i bankportaler, samlar kontoutdrag i olika format från varje bank och stämmer av konton i kalkylark vid månadens slut. Varje manuellt steg är en fördröjning, en kostnad och en risk för bedrägeri eller fel.
Bankerna går dessutom över till ISO 20022, den internationella standarden för finansiella meddelanden, som bär rikare, strukturerad data än de äldre SWIFT MT-formaten. System som inte kan skapa och läsa den halkar efter sina banker.
Vad som förändras för dig
Helautomatisk hantering
Godkända betalningskörningar lämnar ERP-systemet som signerade filer eller API-anrop, och kontoutdragen kommer tillbaka i en form som ERP-systemet matchar själv.
Snabbare bokslut
Avstämning i flera valutor som körs varje dag, i stället för manuella CSV-uppladdningar och kalkylarksjusteringar vid månadens slut.
Varje undantag med en ansvarig person
Avvisade betalningar och omatchade rader hamnar med orsaken i en undantagskö (dead-letter-kö), aldrig borttappade i en inkorg.
Vad vi levererar
Host-to-host och direkt bankanslutning
Anslutningar via SFTP, EBICS och SWIFT samt API:er för open banking och direkta bank-API:er, valda per bank och per land.
Generering av betalningsfiler
Betalningsfiler enligt ISO 20022 pain.001 som byggs från dina betalningskörningar, valideras mot varje banks variant och signeras eller krypteras enligt bankens krav.
Hantering av status och avvisningar
Statusrapporter enligt pain.002 läses tillbaka, så att varje betalning visas som godkänd, avvisad eller väntande, med bankens orsakskod.
Inläsning av kontoutdrag
Dagsslutsutdrag och intradagsrapporter enligt camt.053 och MT940 samlas in, kontrolleras för luckor och dubbletter och läses in i ERP-systemet.
Interbankmeddelanden för banker och fintechbolag
pacs-meddelanden för kreditöverföringar och deras status mellan finansinstitut, kopplade till kärnbanksystemens huvudböcker.
Avstämning i flera valutor
Matchningsregler som stämmer av öppna poster automatiskt över valutor och konton och skickar resten till en undantagskö.
Testunderlag per bank och driftsmanualer
Varje banks testfall körs och dokumenteras för dina revisorer, med larm för saknade filer, misslyckade överföringar och nycklar eller certifikat som snart går ut.
Hur vi arbetar
Kartlägg banker och flöden
Vi listar dina banker, konton, betalningstyper och manuella steg i dag och kommer överens om vilka flöden som går först.
Specificera varje format
Vi arbetar utifrån varje banks implementeringsguide och skriver mappningen, inklusive signering, kryptering och filnamn.
Bygg kopplingarna
Vi bygger export av betalningar, import av status, import av kontoutdrag och matchning, med automatiska tester för varje format.
Testa med varje bank
Vi kör de överenskomna testfallen i bankens testmiljö och rättar det som bankens validering underkänner.
Driftsätt bank för bank
Vi växlar en bank i taget, med den nuvarande processen redo som reserv tills den nya har visat sig fungera.
Övervaka och stötta
Vi bevakar överföringar samt nycklar och certifikat som går ut, och planerar för formatändringar när bankerna aviserar dem.
Rulla i sidled för att se hela ritningen.
ERP till bank: betalningar ut, kontoutdrag in
Godkända betalningar lämnar ERP som signerade ISO 20022-filer över en host-to-host-kanal. Statusrapporter och kontoutdrag kommer tillbaka samma väg och matchas mot öppna poster. Avvisningar och omatchade rader går till ditt team med orsaken bifogad.
- Primärt flöde
- Asynkront
- Undantagsväg
Flödet i 10 steg
Flödet, steg för steg
- Från ERP till Integrationslager: Godkänd betalningskörning, över REST/JSON · IDoc (primärt flöde).
- Från Integrationslager till Säker bankkanal: Signerad och krypterad betalningsfil, över ISO 20022 pain.001 · OpenPGP (primärt flöde).
- Från Säker bankkanal till Bank: Levererad till banken, över SFTP H2H (primärt flöde).
- Från Bank till Säker bankkanal: Statusrapporter och kontoutdrag, över pain.002 · camt.053 · MT940 (asynkront).
- Från Säker bankkanal till Integrationslager: Inhämtade och validerade, över SFTP H2H (asynkront).
- Från Integrationslager till Avstämningsmotor: Kontoutdragsrader, över camt.053 (asynkront).
- Från Avstämningsmotor till ERP: Matchade poster bokförda, över REST/JSON (primärt flöde).
- Från Integrationslager till Treasury- och ekonomiteam: Avvisade betalningar, med orsakskod, över pain.002 RJCT (undantagsväg).
- Från Avstämningsmotor till Treasury- och ekonomiteam: Omatchade rader: en avstämningsdifferens (undantagsväg).
- Från Treasury- och ekonomiteam till ERP: Korrigerade och skickade igen (undantagsväg).
Rulla i sidled för att se hela ritningen.
Open banking: data och betalningar med kundens samtycke
Kunden lämnar samtycke, anslutningen håller tokens, och varje anrop till banken auktoriseras och loggas. När samtycket löper ut eller dras tillbaka frågar appen kunden igen i stället för att fallera tyst.
- Primärt flöde
- Asynkront
- Undantagsväg
Flödet i 7 steg
Flödet, steg för steg
- Från Kund till Din app eller plattform: Lämnar samtycke (primärt flöde).
- Från Din app eller plattform till Open banking-anslutning: Konto- och betalningsbegäranden, över REST/JSON (primärt flöde).
- Från Open banking-anslutning till Bank-API:er eller aggregator: Auktoriserade API-anrop, över OAuth 2.0 · FAPI · REST (primärt flöde).
- Från Bank-API:er eller aggregator till Open banking-anslutning: Saldon, transaktioner och betalningsstatus, över REST/JSON · webhook (asynkront).
- Från Open banking-anslutning till ERP eller huvudbok: Normaliserade transaktioner, över REST/JSON (primärt flöde).
- Från Bank-API:er eller aggregator till Open banking-anslutning: Samtycket har löpt ut eller dragits tillbaka, över HTTP 401 · 403 (undantagsväg).
- Från Open banking-anslutning till Din app eller plattform: Kunden ombeds förnya samtycket (undantagsväg).
Standarder, format och kanaler
Vi bygger utifrån varje banks implementeringsguide, inte enbart utifrån standarden. Att nämna en produkt betyder inte att vi är partner med dess leverantör.
- Bankstandarder och kanaler
- ISO 20022
- pain.001
- pain.002
- camt.052
- camt.053
- camt.054
- MT940
- MT942
- Swift
- EBICS
- SFTP (H2H)
- OpenPGP
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
Bevis i produktion
För en Tier 1-bank i GCC och ett regionalt konglomerat kopplade vi SAP S/4HANA till regionala bankinfrastrukturer via ISO 20022. Betalningar signeras, undantag hamnar i dead-letter-köer och avstämningen över bankkontona sker automatiskt.
Så börjar du
Tydliga krav på banker och format går direkt till ett förslag. Flera banker, länder eller ett odokumenterat äldre gränssnitt börjar vanligen med Blueprint Studio eller Brownfield Diagnostic Bridge.
Vad som händer härnäst
Förberedande samtal
En kostnadsfri förkonsultation online i 30 minuter: vi går igenom dina mål, system och begränsningar.
Mognadsgenomgång
I en kostnadsfri mognadsgenomgång på 48 timmar prövar en ledande arkitekt ditt projekt mot de sex kriterierna för Definition of Ready och rekommenderar det spår som passar.
Val av spår
Projekt med tydlig omfattning får ett bindande förslag inom 3 till 5 arbetsdagar. Projekt i konceptfasen börjar i Blueprint Studio. Ett system i drift som fallerar, är odokumenterat eller behöver integreras börjar med en diagnostik på 1 till 2 veckor. Blueprint Studio och diagnostiken har var sitt fasta pris som anges i förslaget.
Leverans i fem steg
Mobilisering, sprintar med livedemonstrationer, integration och härdning, acceptans och driftsättning, sedan förvaltade tjänster. Efter driftsättningen följer en garantitid, därefter valfri support och förvaltning.
Projekt med fastställt resultat och förvaltade tjänster dygnet runt
Leverans med fast omfattning och milstolpar under namngivna leveransansvariga, samt förvaltade applikationstjänster dygnet runt under SLA-styrning.
Inbäddade specialister och strategisk förstärkning
Ledande ingenjörer och specialister nearshore och på plats, samt inbäddade arkitekter för lösningar, transformation, PQC och integration.
Frågor och svar
Vad är ISO 20022, och varför spelar det roll?
ISO 20022 är den internationella standarden för finansiella meddelanden. Standardens XML-meddelanden bär strukturerad data, som fullständiga namn, adresser och betalningsreferenser, som de äldre SWIFT MT-formaten inte klarar. Banker och betalningssystem har gått över till den, så betalnings- och kontoutdragsfiler som bygger på den stäms av bättre och klarar efterlevnadskontroller oftare.
Vilka bankformat och kanaler hanterar XSIS?
Vi använder pain.001 för betalningar, pain.002 för status, camt.052, camt.053 och camt.054 för rapporter om konton och pacs-meddelanden mellan banker. Vi läser också MT940- och MT942-utdrag som många banker fortfarande skickar. Transporten är host-to-host via SFTP, EBICS, SWIFT eller bank-API:er. Varje bank har sin egen variant av varje format, så vi bygger utifrån dess implementeringsguide.
Vilka ERP-system kan kopplas till banker?
SAP S/4HANA, Oracle Fusion Cloud ERP och NetSuite, Microsoft Dynamics 365, Odoo och Sage, liksom treasury- och egenutvecklade system. När ERP-systemet har en egen modul för bankkommunikation konfigurerar och bygger vi ut den i stället för att bygga runt den.
Hur hålls betalningsfilerna säkra?
Betalningsfiler signeras och krypteras enligt varje banks krav och går bara via den överenskomna kanalen. Nycklar och certifikat förvaras i ditt nyckelvalv eller din hårdvarusäkerhetsmodul, aldrig i kod. Filerna valideras innan de skickas, och varje överföring loggas, så att du kan spåra vem som godkände och skickade varje betalning.
Vad händer när en kontoutdragsrad inte matchar?
Den hamnar i en granskningslista med de troliga kandidaterna och orsaken till att den inte matchade, till exempel ett annat belopp eller en saknad referens. Ditt team åtgärdar den där, och reglerna kan justeras så att samma fall matchar nästa gång. Inget bokförs utan en matchning som du har godkänt.
Vad sätter takten i en bankintegration?
Främst banken, inte koden. Varje bank har egna introduktionssteg, testfönster och godkännanden, och vissa kräver avtal eller nyckelutbyte innan testningen kan börja. Efter mappningssteget ger vi dig en plan per bank och börjar testa med den bank som är redo först.
Vad händer när en bank ändrar sitt format?
Bankerna aviserar formatändringar i förväg, som många gjorde vid övergången från SWIFT MT till ISO 20022. Vi följer dessa aviseringar för de banker vi ansluter, bedömer påverkan och planerar ändringen och dess tester med banken före bankens tidsfrist.
Redo att bygga? Begär ett förslag.
Skicka dina krav eller din offertförfrågan. Våra arkitekter validerar dem och lämnar ett bindande förslag med fast omfattning.
Vad som händer härnäst
Mognadsgenomgång
I en kostnadsfri mognadsgenomgång på 48 timmar prövar en ledande arkitekt ditt projekt mot de sex kriterierna för Definition of Ready och rekommenderar det spår som passar.
Bindande förslag
Efter en arkitekturvalidering utan kostnad får du ett bindande förslag med fast omfattning inom 3 till 5 arbetsdagar: milstolpar, arkitektur, teamstruktur och SLA:er. Vi tecknar ett sekretessavtal (NDA) med dig på begäran, innan du delar dina krav.
Mobilisering
När du har skrivit på börjar våra utvecklingsteam Sprint 0 inom 5 till 10 arbetsdagar från avtalstecknandet.
Leverans i fem steg
Mobilisering, sprintar med livedemonstrationer, integration och härdning, acceptans och driftsättning, sedan förvaltade tjänster. Efter driftsättningen följer en garantitid, därefter valfri support och förvaltning.