Enterprise platforms · Banking
Reconciliation engine for banks and payment firms
We build reconciliation engines for banks and payment firms: matching of statements, payment messages, card files and ledger entries at volume, with rules for exact, tolerance and many-to-many matches, break management for what does not match and an audit trail that finance and auditors accept. It replaces spreadsheets and scripts with one controlled process, and you own the code.
Checklist · Payments
Payment hub and ISO 20022 readiness checklist
A checklist for banks and payment firms planning a payment hub, a real-time payments connection or an ISO 20022 migration: formats, mapping, validation, routing, exceptions, reconciliation and resilience.- 01Eight areas to review before you choose or build a payment platform.
- 02The message and data points that cause rejections: addresses, identifiers and remittance data.
- 03Questions on cut-offs, liquidity and exception handling.
- 04Seven questions to put to any vendor or development partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Source ingestion
Statements, payment messages, card and scheme files, ledger extracts and partner reports loaded through connectors, with checks for completeness and duplicates. - 02
Normalisation
Every source mapped onto a common item model, with amounts, dates, references and parties in comparable form. - 03
Matching rules
Exact, tolerance and rule-based matching on references, amounts and dates, including one-to-many and many-to-many groups and netted settlements. - 04
Rule management
Rules ordered by priority and owned by operations, versioned and tested on historical data before they go live. - 05
Break management
Unmatched items grouped by cause and age, assigned to owners with due dates, escalated by thresholds and linked to the evidence needed to clear them. - 06
Adjustments and postings
Suggested and approved adjusting entries, written to the ledger with the match they explain. - 07
Nostro and settlement views
Position by correspondent, currency and value date, so treasury sees outstanding items that affect liquidity. - 08
Reporting and sign-off
Daily match rates, ageing, high-value breaks and period-end sign-off with evidence kept for audit. - 09
Throughput and scale
High item volumes processed in parallel, with results reproducible from the same inputs.
Reference architecture.
Standards and interfaces
What we design against.
- ISO 20022 camt messages
- camt.053 statements, camt.052 intraday reports and camt.054 notifications as the preferred inputs, with legacy MT formats supported where counterparties still send them.
- Scheme and card settlement files
- Clearing and settlement files from card schemes and payment systems, each with its own layout and cut-off.
- Accounting standards
- Treatment of unreconciled items, suspense accounts and ageing under the bank's accounting policies.
- Control frameworks
- Period-end sign-off, evidence retention and segregation of duties that internal and external audit review.
- OpenAPI
- Interfaces for loading data, retrieving match status and posting adjustments.
- Data retention rules
- Retention of source files and match results for the period policy and regulation require.
Data model
The core entities.
- Source item
- One line from a statement, message, file or ledger, in its original form and in normalised form.
- Match group
- The items matched together, the rule that matched them, the tolerance used and the time.
- Break
- Unmatched item or group, cause category, age, owner, status and linked evidence.
- Rule and rule set
- Match logic, priority, scope, version and the person who approved it.
- Adjustment
- Proposed entry, reason, approver, posting reference and the break it clears.
- Account and period
- Reconciled account, period, open items and sign-off record.
- Run
- Inputs loaded, rule versions used and results, so a run can be reproduced.
When custom development is the right call.
Controls designed in, not added later.
Four-eyes on adjustments
No one can propose and approve the same adjusting entry, and large items need a higher authority.Immutable evidence
Source files and results are stored unaltered with hashes, so a figure can be traced to its origin.Rule change control
Rule edits need approval, are tested on historical data and are dated.Role-based access
Teams see only the accounts and items they own, with read-only views for audit.Reproducibility
A run can be repeated from stored inputs and rule versions to give the same result.
From discovery to a system you run.
- 01
Reconciliation inventory
We list every reconciliation, its sources, volumes, owners and the spreadsheets and scripts behind it today. - 02
Item model and rule design
The common item model and the matching rules are written with operations and tested against a sample of real data. - 03
Build by account group
Reconciliations are moved onto the engine in groups, starting with the highest volume or highest risk. - 04
Parallel run
Each group runs beside the old process until match rates and breaks agree. - 05
Retire the old process
Spreadsheets and scripts are switched off, with period-end sign-off now taken from the engine.
Relevant work
Where to see our work.
Common questions.
- Can the engine match one payment to several ledger entries?
- Yes. Matching supports one-to-many and many-to-many groups, with tolerance on the total, so batched settlements and split payments clear without manual work.
- How do you handle high volumes?
- Items are partitioned by account and date and matched in parallel. Rules run in priority order, and results are reproducible from stored inputs and rule versions.
- Can the engine post adjusting entries?
- It proposes entries from rules, routes them for approval and posts approved entries to the ledger with the match they explain, so the correction and its evidence stay together.
- Does it work with our existing ledger?
- Yes. Ledger extracts come in through connectors, and adjustments go back through the ledger's own interface or file load.
- Who owns the code and the data?
- You do. The code, the rules and the data stay yours.