Reconciliation for remittance providers: one transfer, several records, one close.
How to build a reconciliation workflow that follows money across transfer ledgers, payout partners and bank accounts, investigates the differences and gives finance a close it can inspect.
A customer funds a transfer in pounds. A payout partner delivers money in the destination currency. The internal ledger records the obligation, the fees and the movement of funds. A bank statement records cash on its own timetable. Each system describes part of the same transfer, and finance has to show how the parts fit together.
For a remittance provider, the useful unit of work is the whole reconciliation workflow: gather the records, validate them, match what can be proved, investigate what cannot, and prepare a close that someone can inspect. This article sets out that workflow as Flowmynt builds it, with the financial rules explicit and the decisions accountable. The design and the worked example are illustrative; no customer results are claimed.
Where the work accumulates
The straightforward matches are only part of the job. A bank credit might settle hundreds of transfers after fees. A payout may complete before the partner includes it in a settlement file. A refund can arrive after the original period has closed. Similar amounts are not enough to establish that two records describe the same obligation.
- Reference differences: connect the customer transfer, the internal ledger entry and the partner identifier through a documented mapping.
- Timing differences: keep event time, processing date and bank value date, then apply the agreed cut-off for the account.
- Batch settlements: reconstruct the transactions, fees and adjustments behind one net cash movement.
- Currency differences: preserve funding, payout and settlement amounts in their original currencies, with the rate and terms that connect them.
- Reversals and duplicates: distinguish a repeated event from a second payment, and link each reversal to the original transfer.
Every unresolved item needs an amount, a currency, an age and an owner. Otherwise a queue can look smaller simply because a difference was hidden inside a tolerance or moved into another period.
Five steps, one reconciliation record
Each step reads from and writes to the same record, so a reviewer can follow any figure in the close back to the rows that produced it.
Collect and validate the inputs
Authorised exports or API records are retrieved from the ledger, the payout partners and the banks. The workflow checks which sources were expected, whether they arrived, their record counts and their control totals. An unreadable amount or a missing file becomes an ingestion exception. Every extracted field keeps a link to its source.
Match through approved rules
A deterministic matching engine applies exact identifiers first, then approved composite keys and documented batch relationships. Amounts, currencies, fee treatment, rounding and date windows are rules with versions. A candidate match on an incomplete reference stays unaccepted until the evidence meets the agreed criteria.
Investigate the exceptions
For each open item the workflow follows the transaction history, retrieves the applicable fee schedule and checks payout and settlement events. It assembles a likely explanation with source references: a late settlement, a duplicate callback, a fee variance or a missing partner entry. Where the evidence is incomplete, it records what is missing and assigns the next action.
Check the proposed resolution
A separate control step checks that the cited records exist, that the calculation balances and that the proposal uses an approved rule. Confidence in a well-written explanation cannot authorise a ledger adjustment. Finance owns changes to accounting treatment, disputed fees, write-offs and postings, with approvals bound to the exact proposal reviewed.
Prepare the close
The close pack shows matched positions, source completeness, balances by account and currency, and an aged exception list. Re-running a period preserves the earlier result, so a late-arriving file explains a change rather than overwriting it.
A £250 difference should stay visible
Consider an illustrative GBP settlement batch. Its underlying transfers total £100,000. The agreed partner fees are £750, so the expected bank credit is £99,250. The bank statement shows £99,000. The reconciliation has a £250 difference.
The workflow can reconstruct the batch, show the fee calculation and retrieve any adjustment notice. If no source explains the remaining £250, it leaves an open exception with the evidence attached. It must not invent an extra fee, widen the tolerance or label the difference as FX simply to complete the match.
A reviewer receives a specific question: what explains this £250 reduction against these settlement records? If a later document supplies the answer, the resolution cites that document and keeps the original finding.
Build around the systems already holding the money
Start with one corridor, one partner and one settlement account. Connect through approved APIs or controlled file delivery, map references and define the close boundary. The first workflow reads the existing systems and prepares reconciliation records. It does not need permission to release funds to demonstrate value.
Flowmynt scopes the engineering into reviewed changes inside your systems: a connector with completeness checks, a parser with source references, a versioned matching rule, an exception route and a close report. Each change ships with representative input and an expected result that finance can inspect. Credentials and access are limited to the sources and actions that step requires.
- Replay the same file or callback without counting the same money twice.
- Reject ambiguous currency fields and quarantine records that cannot be parsed reliably.
- Keep financial arithmetic reproducible, with exact decimal handling and explicit rounding.
- Retain source versions, matching rules, evidence and decisions under your access and retention policies.
Prove the workflow before expanding it
Replay completed periods against finance-labelled outcomes, including known bad matches. Then run alongside the existing close with read-only access. Test late files, partial settlements, duplicate callbacks, refunds and reversals. A match rate alone cannot show that the workflow is correct if the denominator excludes records that failed to load.
- Input completeness: expected files and records received, validated and accounted for.
- Match precision: accepted matches that agree with independently reviewed outcomes.
- Coverage: the share of the agreed population reconciled through approved rules.
- Exception age and reopened matches: whether unresolved work is shrinking and resolutions hold.
- Close preparation time: elapsed time from complete inputs to a reviewable pack, measured over comparable periods.
Expansion follows evidence: another partner format, another corridor or another approved action. The aim is a finance team that spends less time assembling the record and more time deciding the differences that need judgement.
Adapted from: Reconciliation, run by AI agents, for a UK remittance giant (Exekova research)
Reconciling across partners and banks?
Send one corridor, one partner and one settlement account. Flowmynt replies with the close boundary, the first connector and matching rule, and a fixed price for the first period run alongside your existing close.
Talk to Flowmynt