
Bank, treasury og ISO 20022-forbindelser
Betalinger ud, kontoudtog ind, afstemt automatisk i alle valutaer
Treasuryteams indtaster stadig betalinger igen og afstemmer kontoudtog manuelt
Mange treasuryteams taster betalinger ind i bankportaler, henter kontoudtog i forskellige formater fra hver bank og afstemmer konti i regneark ved månedsafslutningen. Hvert manuelt trin er en forsinkelse, en omkostning og en risiko for svindel eller fejl.
Bankerne går også over til ISO 20022, den internationale standard for finansielle meddelelser, som rummer rigere og mere strukturerede data end de ældre SWIFT MT-formater. Systemer, der ikke kan danne og læse den, kommer bagud i forhold til deres banker.
Det ændrer sig for dig
Straight-through processing (STP)
Godkendte betalingskørsler forlader ERP-systemet som signerede filer eller API-kald, og kontoudtog kommer tilbage i en form, som ERP-systemet selv kan afstemme.
Hurtigere regnskabsafslutning
Afstemning i flere valutaer, der kører hver dag, i stedet for manuelle CSV-uploads og regnearksrettelser ved månedsafslutningen.
Hver undtagelse har en ansvarlig
Afviste betalinger og uafstemte linjer havner i en dead-letter-undtagelseskø med årsagen og forsvinder aldrig i en postkasse.
Det leverer vi
Host-to-host og direkte bankkonnektivitet
Forbindelser via SFTP, EBICS og SWIFT samt open banking og direkte bank-API’er, valgt pr. bank og pr. land.
Generering af betalingsfiler
ISO 20022 pain.001-betalingsfiler dannet ud fra dine betalingskørsler, valideret mod hver banks variant og signeret eller krypteret, som banken kræver.
Status og håndtering af afvisninger
pain.002-statusrapporter læses tilbage, så hver betaling vises som accepteret, afvist eller afventende med bankens årsagskode.
Indlæsning af kontoudtog
camt.053- og MT940-kontoudtog ved dagens afslutning og intradagsrapporter hentes, kontrolleres for huller og dubletter og indlæses i ERP-systemet.
Interbank-meddelelser til banker og fintechs
pacs-meddelelser om kreditoverførsler og deres status mellem finansielle institutioner, forbundet med kernehovedbøger.
Afstemning i flere valutaer
Afstemningsregler, der automatisk udligner åbne poster på tværs af valutaer og konti og sender resten til en undtagelseskø.
Banktestdokumentation og driftsmanualer
Hver banks testcases køres og dokumenteres for dine revisorer, og der er alarmer ved manglende filer, mislykkede overførsler og nøgler eller certifikater, der er ved at udløbe.
Sådan arbejder vi
Kortlæg banker og flows
Vi opgør dine banker, konti, betalingstyper og nuværende manuelle trin og aftaler, hvilke flows der kommer først.
Specificer hvert format
Vi arbejder ud fra hver banks implementeringsvejledning og skriver mappingen, herunder signering, kryptering og navngivning af filer.
Byg konnektorerne
Vi bygger eksport af betalinger, import af status, import af kontoudtog og afstemning med automatiserede tests for hvert format.
Test med hver bank
Vi kører de aftalte testcases i bankens testmiljø og retter det, som bankens validering afviser.
Idriftsæt bank for bank
Vi skifter én bank ad gangen og har den nuværende proces klar som reserve, indtil den nye har vist sig at virke.
Overvåg og understøt
Vi holder øje med overførsler, nøgler og certifikaters udløb og planlægger formatændringer, efterhånden som bankerne varsler dem.
Rul sidelæns for at se hele tegningen.
ERP til bank: betalinger ud, kontoudtog ind
Godkendte betalinger forlader ERP-systemet som signerede ISO 20022-filer over en host-to-host-kanal. Statusrapporter og kontoudtog kommer tilbage samme vej og afstemmes med åbne poster. Afvisninger og uafstemte linjer går til dit team med årsagen vedhæftet.
- Primært flow
- Asynkron
- Undtagelsessti
Forløbet i 10 trin
Forløbet, trin for trin
- Fra ERP til Integrationslag: Godkendt betalingskørsel, over REST/JSON · IDoc (primært flow).
- Fra Integrationslag til Sikker bankkanal: Signeret og krypteret betalingsfil, over ISO 20022 pain.001 · OpenPGP (primært flow).
- Fra Sikker bankkanal til Bank: Leveret til banken, over SFTP H2H (primært flow).
- Fra Bank til Sikker bankkanal: Statusrapporter og kontoudtog, over pain.002 · camt.053 · MT940 (asynkron).
- Fra Sikker bankkanal til Integrationslag: Hentet og valideret, over SFTP H2H (asynkron).
- Fra Integrationslag til Afstemningsmotor: Linjer i kontoudtog, over camt.053 (asynkron).
- Fra Afstemningsmotor til ERP: Afstemte poster bogført, over REST/JSON (primært flow).
- Fra Integrationslag til Treasury- og økonomiteam: Afviste betalinger, med årsagskoden, over pain.002 RJCT (undtagelsessti).
- Fra Afstemningsmotor til Treasury- og økonomiteam: Uafstemte linjer: en afstemningsdifference (undtagelsessti).
- Fra Treasury- og økonomiteam til ERP: Rettet og genindsendt (undtagelsessti).
Rul sidelæns for at se hele tegningen.
Open banking: data og betalinger med kundens samtykke
Kunden giver samtykke, konnektoren opbevarer tokens, og hvert kald til banken er autoriseret og logget. Når samtykket udløber eller trækkes tilbage, spørger appen kunden igen i stedet for at fejle i stilhed.
- Primært flow
- Asynkron
- Undtagelsessti
Forløbet i 7 trin
Forløbet, trin for trin
- Fra Kunde til Din app eller platform: Giver samtykke (primært flow).
- Fra Din app eller platform til Forbindelse til open banking: Konto- og betalingsanmodninger, over REST/JSON (primært flow).
- Fra Forbindelse til open banking til Bank-API’er eller aggregator: Autoriserede API-kald, over OAuth 2.0 · FAPI · REST (primært flow).
- Fra Bank-API’er eller aggregator til Forbindelse til open banking: Saldi, transaktioner og betalingsstatus, over REST/JSON · webhook (asynkron).
- Fra Forbindelse til open banking til ERP eller hovedbog: Normaliserede transaktioner, over REST/JSON (primært flow).
- Fra Bank-API’er eller aggregator til Forbindelse til open banking: Samtykke udløbet eller trukket tilbage, over HTTP 401 · 403 (undtagelsessti).
- Fra Forbindelse til open banking til Din app eller platform: Kunden bedt om at forny samtykket (undtagelsessti).
Standarder, formater og kanaler
Vi bygger ud fra hver enkelt banks implementeringsvejledning, ikke fra standarden alene. At nævne et produkt betyder ikke, at vi er partner med leverandøren.
- Bankstandarder og bankkanaler
- 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
Dokumenteret i produktionen
For en tier-1 GCC-bank og et regionalt konglomerat forbandt vi SAP S/4HANA med regional betalingsinfrastruktur via ISO 20022. Betalinger signeres, undtagelser havner i dead-letter-køer, og afstemningen på tværs af bankkontiene sker automatisk.
Sådan begynder du
Klare krav til banker og formater går direkte til et forslag. Flere banker, flere lande eller en udokumenteret ældre grænseflade begynder som regel med Blueprint Studio eller Brownfield Diagnostic Bridge.
Det sker der nu
Forhåndskonsultation
En gratis online forhåndskonsultation på 30 minutter: vi gennemgår dine mål, systemer og begrænsninger.
Parathedsanalyse
I en gratis parathedsanalyse på 48 timer tjekker en ledende arkitekt dit projekt op mod de 6 punkter i Definition of Ready og anbefaler det spor, der passer.
Valg af spor
Projekter med et klart omfang modtager et bindende forslag inden for 3 til 5 hverdage. Projekter i konceptfasen starter i Blueprint Studio. Et system i drift, der fejler, er udokumenteret eller skal integreres, starter med en diagnosticering på 1 til 2 uger. Blueprint Studio og diagnosticeringen har hver et fast honorar, som er angivet i forslaget.
Levering i fem faser
Mobilisering, sprints med demonstrationer, integration og hærdning, accept og idriftsættelse samt derefter administrerede tjenester. Efter idriftsættelsen følger en garantiperiode, derefter valgfri support og vedligeholdelse.
Projekter med fast resultat og administrerede tjenester døgnet rundt
Milepælsdrevet levering med fast omfang og navngivne leveringsansvarlige samt administrerede applikationstjenester døgnet rundt under SLA-styring.
Indlejrede specialister og strategisk teamforstærkning
Ledende ingeniører og specialister nearshore og på stedet samt indlejrede løsnings-, transformations-, PQC- og integrationsarkitekter.
Spørgsmål og svar
Hvad er ISO 20022, og hvorfor betyder det noget?
ISO 20022 er den internationale standard for finansielle meddelelser. Dens XML-meddelelser indeholder strukturerede data, såsom fulde navne, adresser og betalingsoplysninger, som de ældre SWIFT MT-formater ikke kan rumme. Banker og betalingssystemer er gået over til den, så betalingsfiler og kontoudtog, der bygger på den, afstemmes bedre og består compliancekontroller oftere.
Hvilke bankformater og kanaler arbejder I med?
Vi bruger pain.001 til betalinger, pain.002 til status, camt.052, camt.053 og camt.054 til kontorapporter og pacs-meddelelser mellem banker. Vi læser også de MT940- og MT942-kontoudtog, som mange banker stadig sender. Transporten sker via host-to-host SFTP, EBICS, SWIFT eller bank-API’er. Hver bank har sin egen variant af hvert format, så vi bygger ud fra dens implementeringsvejledning.
Hvilke ERP-systemer kan I forbinde med banker?
SAP S/4HANA, Oracle Fusion Cloud ERP og NetSuite, Microsoft Dynamics 365, Odoo og Sage samt treasurysystemer og specialudviklede systemer. Hvor ERP-systemet har sit eget bankkommunikationsmodul, konfigurerer og udvider vi det i stedet for at bygge uden om det.
Hvordan holder I betalingsfiler sikre?
Betalingsfiler signeres og krypteres, som hver bank kræver, og sendes kun via den aftalte kanal. Nøgler og certifikater opbevares i din nøgleboks eller dit hardwaresikkerhedsmodul (HSM), aldrig i koden. Filerne valideres, før de sendes, og hver overførsel logges, så du kan spore, hvem der godkendte og sendte hver betaling.
Hvad sker der, når en linje i et kontoudtog ikke kan afstemmes?
Den havner på en gennemgangsliste med de sandsynlige kandidater og årsagen til, at den ikke kunne afstemmes, for eksempel et andet beløb eller en manglende reference. Dit team afklarer den der, og reglerne kan justeres, så det samme tilfælde afstemmes næste gang. Intet bogføres i hovedbogen uden en afstemning, du har godkendt.
Hvad bestemmer tempoet i en bankintegration?
Mest banken, ikke koden. Hver bank fastlægger sine egne onboardingtrin, testvinduer og godkendelser, og nogle kræver kontrakter eller nøgleudveksling, før testen kan begynde. Efter kortlægningen giver vi dig en plan pr. bank og begynder at teste med den bank, der først er klar.
Hvad sker der, når en bank ændrer sit format?
Bankerne varsler formatændringer på forhånd, som mange gjorde ved overgangen fra SWIFT MT til ISO 20022. Vi følger disse meddelelser for de banker, vi forbinder til, vurderer konsekvenserne og planlægger ændringen og dens tests med banken inden dens tidsfrist.
Klar til at bygge? Bed om et forslag.
Send dine krav eller din RFP. Vores arkitekter validerer dem og sender et bindende forslag med fast omfang retur.
Det sker der nu
Parathedsanalyse
I en gratis parathedsanalyse på 48 timer tjekker en ledende arkitekt dit projekt op mod de 6 punkter i Definition of Ready og anbefaler det spor, der passer.
Bindende forslag
Efter arkitekturvalidering uden omkostninger modtager du et bindende forslag med fast omfang inden for 3 til 5 hverdage: milepæle, arkitektur, teamstruktur og SLA’er. Vi underskriver efter anmodning en fortrolighedsaftale (NDA) med dig, før du deler dine krav.
Mobilisering
Når du har underskrevet, begynder vores ingeniørteams på sprint 0 inden for 5 til 10 hverdage efter kontraktunderskrivelse.
Levering i fem faser
Mobilisering, sprints med demonstrationer, integration og hærdning, accept og idriftsættelse samt derefter administrerede tjenester. Efter idriftsættelsen følger en garantiperiode, derefter valgfri support og vedligeholdelse.
