Bank, treasury og ISO 20022-tilkobling
Betalinger ut, kontoutskrifter inn, avstemt automatisk i alle valutaer
Treasury-team taster fortsatt betalinger på nytt og avstemmer kontoutskrifter manuelt
Mange treasury-team taster betalinger inn i bankportaler, henter kontoutskrifter i ulike formater fra hver bank og avstemmer kontoer i regneark ved månedsslutt. Hvert manuelt steg er en forsinkelse, en kostnad og en mulighet for svindel eller feil.
Bankene går også over til ISO 20022, den internasjonale standarden for finansielle meldinger, som bærer rikere strukturerte data enn de eldre SWIFT MT-formatene. Systemer som ikke kan produsere og lese den, blir hengende etter bankene sine.
Det som endres for deg
Gjennomgående behandling
Godkjente betalingskjøringer forlater ERP-systemet som signerte filer eller API-kall, og kontoutskrifter kommer tilbake i en form ERP-systemet avstemmer selv.
Raskere månedsslutt
Avstemming i flere valutaer som kjøres hver dag, i stedet for manuelle CSV-opplastinger og regnearkjusteringer ved månedsslutt.
Hvert avvik har en person
Avviste betalinger og uavstemte linjer ender i en unntakskø for dead letter med årsak, og går aldri tapt i en e-postboks.
Det vi leverer
Host-to-host og direkte banktilkobling
Tilkoblinger over SFTP, EBICS og SWIFT, og open banking- og direkte bank-API-er, valgt per bank og per land.
Generering av betalingsfiler
ISO 20022 pain.001-betalingsfiler bygget fra betalingskjøringene dine, validert mot hver banks variant og signert eller kryptert slik den krever.
Håndtering av status og avvisning
pain.002-statusrapporter leses tilbake, slik at hver betaling vises som godtatt, avvist eller ventende, med bankens årsakskode.
Innlesing av kontoutskrifter
camt.053- og MT940-kontoutskrifter for dagens slutt og intradagrapporter hentes, kontrolleres for hull og duplikater og lastes inn i ERP-systemet.
Interbankmeldinger for banker og fintech-selskaper
pacs-meldinger for kredittoverføringer og deres status mellom finansinstitusjoner, koblet til hovedbøkene i kjernebanksystemene.
Avstemming i flere valutaer
Avstemmingsregler som utligner åpne poster automatisk på tvers av valutaer og kontoer, og sender resten til en unntakskø.
Testdokumentasjon fra banker og driftshåndbøker
Hver banks testtilfeller kjøres og dokumenteres for revisor, og varsler for manglende filer, mislykkede overføringer og nøkler eller sertifikater som utløper.
Slik arbeider vi
Kartlegg banker og flyter
Vi kartlegger bankene, kontoene, betalingstypene og de manuelle stegene du har i dag, og blir enige om hvilke flyter som går først.
Spesifiser hvert format
Vi arbeider ut fra hver banks implementeringsveiledning og skriver mappingen, inkludert signering, kryptering og filnavn.
Bygg koblingene
Vi bygger betalingseksport, statusimport, kontoutskriftsimport og avstemming, med automatiserte tester for hvert format.
Test med hver bank
Vi kjører de avtalte testtilfellene i bankens testmiljø og retter det bankens validering avviser.
Idriftsettelse bank for bank
Vi bytter én bank om gangen, med dagens prosess klar som reserve til den nye er bevist.
Overvåk og støtt
Vi følger med på overføringer, nøkler og sertifikatutløp, og planlegger for formatendringer når bankene varsler dem.
Rull sidelengs for å se hele tegningen.
ERP til bank: betalinger ut, kontoutskrifter inn
Godkjente betalinger forlater ERP-systemet som signerte ISO 20022-filer over en host-to-host-kanal. Statusrapporter og kontoutskrifter kommer tilbake samme vei og matches mot åpne poster. Avvisninger og linjer uten match går til teamet ditt med årsaken vedlagt.
- Hovedforløp
- Asynkron
- Unntaksbane
Forløpet i 10 steg
Forløpet, steg for steg
- Fra ERP til Integreringslag: Godkjent betalingskjøring, over REST/JSON · IDoc (hovedforløp).
- Fra Integreringslag til Sikker bankkanal: Signert og kryptert betalingsfil, over ISO 20022 pain.001 · OpenPGP (hovedforløp).
- Fra Sikker bankkanal til Bank: Levert til banken, over SFTP H2H (hovedforløp).
- Fra Bank til Sikker bankkanal: Statusrapporter og kontoutskrifter, over pain.002 · camt.053 · MT940 (asynkron).
- Fra Sikker bankkanal til Integreringslag: Samlet inn og validert, over SFTP H2H (asynkron).
- Fra Integreringslag til Avstemmingsmotor: Kontoutskriftslinjer, over camt.053 (asynkron).
- Fra Avstemmingsmotor til ERP: Avstemte poster postert, over REST/JSON (hovedforløp).
- Fra Integreringslag til Treasury- og finans teamet: Avviste betalinger, med årsakskode, over pain.002 RJCT (unntaksbane).
- Fra Avstemmingsmotor til Treasury- og finans teamet: Uavstemte linjer: et avstemmingsavvik (unntaksbane).
- Fra Treasury- og finans teamet til ERP: Korrigert og sendt på nytt (unntaksbane).
Rull sidelengs for å se hele tegningen.
Open banking: data og betalinger med kundens samtykke
Kunden gir samtykke, koblingen holder tokenene, og hvert kall til banken autoriseres og logges. Når samtykket utløper eller trekkes tilbake, spør appen kunden på nytt i stedet for å feile i det stille.
- Hovedforløp
- Asynkron
- Unntaksbane
Forløpet i 7 steg
Forløpet, steg for steg
- Fra Kunde til Appen eller plattformen din: Gir samtykke (hovedforløp).
- Fra Appen eller plattformen din til Open banking-kobling: Konto- og betalingsforespørsler, over REST/JSON (hovedforløp).
- Fra Open banking-kobling til Bank-API-er eller aggregator: Autoriserte API-kall, over OAuth 2.0 · FAPI · REST (hovedforløp).
- Fra Bank-API-er eller aggregator til Open banking-kobling: Saldoer, transaksjoner og betalingsstatus, over REST/JSON · webhook (asynkron).
- Fra Open banking-kobling til ERP eller hovedbok: Normaliserte transaksjoner, over REST/JSON (hovedforløp).
- Fra Bank-API-er eller aggregator til Open banking-kobling: Samtykke utløpt eller trukket tilbake, over HTTP 401 · 403 (unntaksbane).
- Fra Open banking-kobling til Appen eller plattformen din: Kunden bes fornye samtykket (unntaksbane).
Standarder, formater og kanaler
Vi bygger ut fra hver banks implementeringsveiledning, ikke ut fra standarden alene. Å nevne et produkt betyr ikke partnerskap 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
Bevist i produksjon
For en Tier-1-bank i GCC og et regionalt konglomerat koblet vi SAP S/4HANA til regional betalingsinfrastruktur over ISO 20022. Betalinger signeres, unntak havner i dead-letter-køer, og avstemmingen på tvers av bankkontoene er automatisk.
Slik starter du
Tydelige bank- og formatkrav går rett til et forslag. Flere banker, land eller et udokumentert eldre grensesnitt starter vanligvis med Blueprint Studio eller Brownfield Diagnostic Bridge.
Hva skjer videre
Forhåndssamtale
En gratis forhåndssamtale på 30 minutter på nett: vi går gjennom målene, systemene og begrensningene dine.
Modenhetsvurdering
I en gratis modenhetsvurdering innen 48 timer kontrollerer en ledende arkitekt prosjektet ditt mot definisjonen av klar (6 punkter) og anbefaler sporet som passer.
Valg av spor
Prosjekter med definert omfang får et bindende forslag innen 3 til 5 virkedager. Prosjekter i konseptfasen starter i Blueprint Studio. Et system i drift som svikter, er udokumentert eller trenger integrasjon, starter med en diagnose på 1 til 2 uker. Blueprint Studio og diagnosen har hver en fastpris som angis i forslaget.
Leveranse i fem trinn
Mobilisering, sprinter med livedemoer, integrasjon og herding, godkjenning og idriftsettelse, deretter forvaltede tjenester. Etter idriftsettelsen kommer en garantiperiode, deretter valgfri støtte og vedlikehold.
Prosjekter med fast resultat og forvaltede tjenester døgnet rundt
Leveranse med fast omfang og milepæler, med navngitte leveranseledere, og forvaltede applikasjonstjenester døgnet rundt under SLA-styring.
Innebygde spesialister og strategisk forsterkning
Nære og lokale ledende ingeniører og spesialister, og innebygde løsnings-, transformasjons-, PQC- og integrasjonsarkitekter.
Spørsmål og svar
Hva er ISO 20022, og hvorfor er det viktig?
ISO 20022 er den internasjonale standarden for finansielle meldinger. XML-meldingene bærer strukturerte data, som fulle navn, adresser og betalingsinformasjon, som de eldre SWIFT MT-formatene ikke kan. Banker og betalingssystemer har gått over til den, så betalings- og kontoutskriftsfiler bygget på den avstemmes bedre og består etterlevelseskontroller oftere.
Hvilke bankformater og kanaler arbeider dere med?
Vi bruker pain.001 for betalinger, pain.002 for status, camt.052, camt.053 og camt.054 for kontoutskrifter, og pacs-meldinger mellom banker. Vi leser også MT940- og MT942-kontoutskrifter som mange banker fortsatt sender. Transport er host-to-host SFTP, EBICS, SWIFT eller bank-API-er. Hver bank har sin egen variant av hvert format, så vi bygger ut fra dens implementeringsveiledning.
Hvilke ERP-systemer kan dere koble til banker?
SAP S/4HANA, Oracle Fusion Cloud ERP og NetSuite, Microsoft Dynamics 365, Odoo og Sage, samt treasury og skreddersydde systemer. Der ERP-systemet har egen bankkommunikasjonsmodul, konfigurerer og utvider vi den i stedet for å bygge rundt den.
Hvordan sikrer dere betalingsfiler?
Betalingsfiler signeres og krypteres slik hver bank krever, og går bare over den avtalte kanalen. Nøkler og sertifikater oppbevares i nøkkelhvelvet eller maskinvaremodulen for sikkerhet (HSM) din, aldri i kode. Filene valideres før de sendes, og hver overføring logges, så du kan spore hvem som godkjente og sendte hver betaling.
Hva skjer når en kontoutskriftslinje ikke samsvarer?
Den havner i en gjennomgangsliste med de sannsynlige kandidatene og årsaken til at den ikke samsvarte, for eksempel et annet beløp eller en manglende referanse. Teamet ditt avklarer den der, og reglene kan justeres slik at samme tilfelle samsvarer neste gang. Ingenting posteres i hovedboken uten en avstemming du har godkjent.
Hva setter tempoet i en bankintegrasjon?
For det meste banken, ikke koden. Hver bank har egne kundeetableringstrinn, testvinduer og godkjenninger, og noen krever kontrakter eller nøkkelutveksling før testingen kan starte. Etter mapping-steget gir vi deg en plan per bank og starter testingen med den banken som er klar først.
Hva skjer når en bank endrer formatet sitt?
Banker varsler formatendringer i forkant, slik mange gjorde ved overgangen fra SWIFT MT til ISO 20022. Vi følger disse varslene for bankene vi kobler til, vurderer konsekvensene og planlegger endringen og testene med banken før fristen.
Klar til å bygge? Be om forslag.
Send kravene dine eller en anmodning om forslag (RFP). Arkitektene våre validerer dem og returnerer et bindende forslag med fast omfang.
Hva skjer videre
Modenhetsvurdering
I en gratis modenhetsvurdering innen 48 timer kontrollerer en ledende arkitekt prosjektet ditt mot definisjonen av klar (6 punkter) og anbefaler sporet som passer.
Bindende forslag
Etter arkitekturvalidering uten kostnad mottar du et bindende forslag med fast omfang innen 3 til 5 virkedager: milepæler, arkitektur, teamstruktur og SLA-er. Vi signerer en konfidensialitetsavtale (NDA) med deg på forespørsel, før du deler kravene dine.
Mobilisering
Når du har signert, starter utviklingsteamene våre sprint 0 innen 5 til 10 virkedager etter kontraktsignering.
Leveranse i fem trinn
Mobilisering, sprinter med livedemoer, integrasjon og herding, godkjenning og idriftsettelse, deretter forvaltede tjenester. Etter idriftsettelsen kommer en garantiperiode, deretter valgfri støtte og vedlikehold.