Banking, treasury and ISO 20022 connectivity
Payments out, statements in, reconciled automatically in every currency
Treasury teams still rekey payments and match statements by hand
Many treasury teams key payments into banking portals, collect statements in different formats from each bank and reconcile accounts in spreadsheets at month-end. Every manual step is a delay, a cost and a chance of fraud or error.
Banks are also moving to ISO 20022, the international standard for financial messages, which carries richer, structured data than the older SWIFT MT formats. Systems that cannot produce and read it fall behind their banks.
What changes for you
Straight-through processing
Approved payment runs leave the ERP as signed files or API calls, and statements come back in a form the ERP matches on its own.
A faster close
Multi-currency reconciliation that runs every day, instead of manual CSV uploads and end-of-month spreadsheet adjustments.
Every exception with a person
Rejected payments and unmatched lines land in a dead-letter exception queue with the reason, never lost in a mailbox.
What we deliver
Host-to-host and direct bank connectivity
Connections over SFTP, EBICS and SWIFT, and open-banking and direct bank APIs, chosen per bank and per country.
Payment file generation
ISO 20022 pain.001 payment files built from your payment runs, validated against each bank's variant and signed or encrypted as it requires.
Status and rejection handling
pain.002 status reports read back, so every payment shows as accepted, rejected or pending, with the bank's reason code.
Statement ingestion
camt.053 and MT940 end-of-day statements and intraday reports collected, checked for gaps and duplicates, and loaded into the ERP.
Interbank messaging for banks and fintechs
pacs messages for credit transfers and their status between financial institutions, connected to core banking ledgers.
Multi-currency reconciliation
Matching rules that clear open items automatically across currencies and accounts, and send the rest to an exception queue.
Bank test evidence and runbooks
Each bank's test cases run and recorded for your auditors, and alerts for missing files, failed transfers and expiring keys or certificates.
How we work
Map banks and flows
We list your banks, accounts, payment types and manual steps today, and agree which flows go first.
Specify each format
We work from each bank's implementation guide and write the mapping, including signing, encryption and file naming.
Build the connectors
We build payment export, status import, statement import and matching, with automated tests for every format.
Test with each bank
We run the agreed test cases in the bank's test environment and fix whatever the bank's validation rejects.
Go live bank by bank
We switch one bank at a time, with the current process ready as a fallback until the new one is proven.
Monitor and support
We watch transfers, keys and certificate expiry, and plan for format changes as banks announce them.
Scroll sideways to see the whole drawing.
ERP to bank: payments out, statements in
Approved payments leave the ERP as signed ISO 20022 files over a host-to-host channel. Status reports and statements come back the same way and are matched to open items. Rejections and unmatched lines go to your team with the reason attached.
- Primary flow
- Asynchronous
- Exception path
The flow in 10 steps
The flow, step by step
- From ERP to Integration layer: Approved payment run, over REST/JSON · IDoc (primary flow).
- From Integration layer to Secure bank channel: Signed and encrypted payment file, over ISO 20022 pain.001 · OpenPGP (primary flow).
- From Secure bank channel to Bank: Delivered to the bank, over SFTP H2H (primary flow).
- From Bank to Secure bank channel: Status reports and statements, over pain.002 · camt.053 · MT940 (asynchronous).
- From Secure bank channel to Integration layer: Collected and validated, over SFTP H2H (asynchronous).
- From Integration layer to Reconciliation engine: Statement lines, over camt.053 (asynchronous).
- From Reconciliation engine to ERP: Matched entries posted, over REST/JSON (primary flow).
- From Integration layer to Treasury and finance team: Rejected payments, with the reason code, over pain.002 RJCT (exception path).
- From Reconciliation engine to Treasury and finance team: Unmatched lines: a reconciliation break (exception path).
- From Treasury and finance team to ERP: Corrected and resubmitted (exception path).
Scroll sideways to see the whole drawing.
Open banking: data and payments with the customer’s consent
The customer grants consent, the connector holds the tokens, and every call to the bank is authorised and logged. When consent expires or is withdrawn, the app asks the customer again instead of failing quietly.
- Primary flow
- Asynchronous
- Exception path
The flow in 7 steps
The flow, step by step
- From Customer to Your app or platform: Grants consent (primary flow).
- From Your app or platform to Open banking connector: Account and payment requests, over REST/JSON (primary flow).
- From Open banking connector to Bank APIs or aggregator: Authorised API calls, over OAuth 2.0 · FAPI · REST (primary flow).
- From Bank APIs or aggregator to Open banking connector: Balances, transactions and payment status, over REST/JSON · webhook (asynchronous).
- From Open banking connector to ERP or ledger: Normalised transactions, over REST/JSON (primary flow).
- From Bank APIs or aggregator to Open banking connector: Consent expired or withdrawn, over HTTP 401 · 403 (exception path).
- From Open banking connector to Your app or platform: Customer asked to renew consent (exception path).
Standards, formats and channels
We build from each bank's implementation guide, not from the standard alone. Naming a product does not mean a partnership with its vendor.
- Banking standards and channels
- 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
Proof in production
For a Tier-1 GCC bank and regional conglomerate, we connected SAP S/4HANA to regional banking rails over ISO 20022. Payments are signed, exceptions land in dead-letter queues, and reconciliation across its bank accounts is automatic.
How to start
Clear bank and format requirements go straight to a proposal. Several banks, countries or an undocumented legacy interface usually start with the Blueprint Studio or the Brownfield Diagnostic Bridge.
What happens next
Pre-consulting session
A free 30-minute online pre-consulting session: we go through your goals, systems and constraints.
Readiness review
In a free 48-hour readiness review, a Principal Architect checks your project against the 6-point Definition of Ready and recommends the track that fits.
Choosing the track
Scope-ready projects receive a binding proposal within 3–5 business days. Concept-stage projects start in the Blueprint Studio. A live system that is failing, undocumented or needs integration starts with a diagnostic of 1–2 weeks. The Blueprint Studio and the diagnostic each have a fixed fee, quoted in the proposal.
Delivery in five stages
Mobilisation, sprints with live demonstrations, integration and hardening, acceptance and go-live, then managed services. After launch comes a warranty period, then optional support and maintenance.
Fixed-outcome projects and round-the-clock managed services
Fixed-scope, milestone-driven delivery with named delivery leads, and round-the-clock application managed services under SLA governance.
Embedded specialists and strategic augmentation
Nearshore and on-site principal engineers and specialists, and embedded solution, transformation, PQC and integration architects.
Questions and answers
What is ISO 20022, and why does it matter?
ISO 20022 is the international standard for financial messages. Its XML messages carry structured data, such as full names, addresses and remittance details, that the older SWIFT MT formats cannot. Banks and payment systems have moved to it, so payment and statement files built on it reconcile better and pass compliance checks more often.
Which bank formats and channels do you work with?
We use pain.001 for payments, pain.002 for status, camt.052, camt.053 and camt.054 for account reports, and pacs messages between banks. We also read the MT940 and MT942 statements many banks still send. Transport is host-to-host SFTP, EBICS, SWIFT or bank APIs. Each bank has its own variant of each format, so we build from its implementation guide.
Which ERP systems can you connect to banks?
SAP S/4HANA, Oracle Fusion Cloud ERP and NetSuite, Microsoft Dynamics 365, Odoo and Sage, as well as treasury and custom systems. Where the ERP has its own bank communication module, we configure and extend it rather than build around it.
How do you keep payment files secure?
Payment files are signed and encrypted as each bank requires and travel only over the agreed channel. Keys and certificates are kept in your key vault or hardware security module, never in code. Files are validated before they are sent, and every transfer is logged, so you can trace who approved and sent each payment.
What happens when a statement line does not match?
It goes to a review list with the likely candidates and the reason it did not match, such as a different amount or a missing reference. Your team clears it there, and the rules can be adjusted so the same case matches next time. Nothing is posted to the ledger without a match you approved.
What sets the pace of a bank integration?
Mostly the bank, not the code. Each bank sets its own onboarding steps, test windows and approvals, and some need contracts or key exchanges before testing can start. After the mapping step we give you a plan per bank and start testing with whichever bank is ready first.
What happens when a bank changes its format?
Banks announce format changes in advance, as many did when moving from SWIFT MT to ISO 20022. We follow those notices for the banks we connect, assess the impact, and schedule the change and its tests with the bank before its deadline.
Ready to build? Ask for a proposal.
Send your requirements or RFP. Our architects validate them and return a binding, fixed-scope proposal.
What happens next
Readiness review
In a free 48-hour readiness review, a Principal Architect checks your project against the 6-point Definition of Ready and recommends the track that fits.
Binding proposal
After architecture validation at no cost, you receive a binding, fixed-scope proposal within 3–5 business days: milestones, architecture, team structure and SLAs. We sign a non-disclosure agreement (NDA) with you on request, before you share your requirements.
Mobilisation
Once you sign, our engineering pods begin Sprint 0 within 5–10 business days of contract signature.
Delivery in five stages
Mobilisation, sprints with live demonstrations, integration and hardening, acceptance and go-live, then managed services. After launch comes a warranty period, then optional support and maintenance.