Money movement
Payouts, transfers, settlement and FX on a provable double-entry ledger.
Payouts get judged twice, on arrival time and on how cleanly the books close afterwards. Oxagile Financial Services builds the payout, transfer and settlement layer, with rail selection per corridor, ISO 20022 message handling, FX rates captured at quote time, and a double-entry ledger where each movement carries its offsetting entry.
Where it fits
The problem
Payout files get assembled in a spreadsheet and uploaded to a bank portal. Status arrives as a next-day report, so support answers customer questions by phoning the operations desk. FX rates come from whatever the treasury sheet held that morning, and settlement breaks surface a week later when a partner disputes a statement.
What we build
A ledger service with double-entry postings, balance snapshots and an append-only event log. Rail adapters for instant schemes, local batch credits, wires and card payouts. ISO 20022 payment initiation and status messaging, corridor routing aware of cost and cut-off, FX quotes captured with the transaction, and automated matching plus an exception queue.
How we engage
Senior engineers with bank integration history work in your cloud and your repositories, next to your treasury and operations teams. Reconciliation rules get written against your historical statement files. Runbooks cover cut-offs, stuck payments and returns. After the engagement your team holds the ledger, the rail adapters and the bank test evidence.
What we build
Six components move the money and leave a record that stands up to review.
Double-entry ledger
A movement posts balanced entries against named accounts, backed by an append-only event log and periodic balance snapshots for fast reads. Platforms that track balances in a mutable column cannot explain how yesterday's figure arose. Here a balance is derived, replayable, and comparable against the bank statement for the same window.
Rail selection
Corridor rules choose between instant schemes, local batch credits, wires and card payouts using cost, cut-off time and amount. Operations teams who route by habit pay wire fees on small transfers and miss same-day windows. Each routing decision gets logged with its reason, so treasury can review the pattern later.
ISO 20022 messaging
Payment initiation, status and return messages follow ISO 20022 schemas, validated against the scheme rulebook before submission and mapped into your internal event model. Teams who maintain hand-built fixed-width files discover a bank's format change through a rejection batch. Schema tests catch that in the pipeline instead.
FX handling
A quote gets captured with the transaction, including rate, spread and source, then held against the ledger entry so the customer receipt and the treasury report agree. Spot rates pulled at posting time drift away from what the customer was shown, and the difference becomes a manual write-off nobody wants to own.
Returns and exceptions
Returns, recalls, stuck payments and duplicate submissions land in a queue with the evidence attached and a defined action per case. Support teams who email the operations desk and wait lose a day per query. Idempotency keys plus reconciliation against bank status keep a retry from paying a beneficiary twice.
Settlement matching
Bank statements, scheme reports and partner files match against ledger entries through automated matching rules, with tolerances set per rail and an exception queue for the remainder. Fees and currency differences post to their own accounts. Operations teams stop reconciling a month of payouts by eye before an audit.
Payouts you can trace to the entry
Rail routing, ISO 20022 messaging and a double-entry ledger with automated matching, so a payout has both a status and an offsetting entry.
How we work
Discover
Systems, constraints, and the regulation you operate under get mapped before implementation starts, so the design accounts for what already runs and for what examiners will ask about.
Architect
A design that fits your stack. Integration-first, self-hostable, and built to change as rules, regulation, and volume do.
Build
Senior engineers ship in tight increments, each tested and reviewed as it goes, so the system is reviewable at every step instead of only at the end.
Harden
Security, compliance, and load-testing run inside the build, so controls, audit trails, and peak-volume behavior are proven before launch.
Run
The handover includes clean, documented systems, with the option to keep the same engineers operating them once they are live.
Why Oxagile
Bank integration experience
Our engineers have run bank certification cycles, so the plan accounts for test-file rounds, cut-off calendars and the weeks a scheme takes to approve a change. Projects that treat a bank connection as one more REST call slip at certification, then find the sandbox behaves unlike production once volume arrives.
Treasury sits in the design
Cut-off times, funding accounts, buffer policy and FX spread ownership come from your treasury team during design rather than after launch. Payout systems built without them park customer money in the wrong account and produce reports treasury declines to sign. Their reconciliation format becomes the acceptance test.
Proof for the auditor
The event log, balance snapshots and matching results give an auditor a path between a customer payout and its line on a bank statement. Teams who answer sampling requests with screenshots and email threads lose weeks per cycle. A queryable trail turns that into an export, with open exceptions listed rather than buried.
Questions
Do we need our own banking licence for this?
You need a regulated partner, and we are not one. We build the software that talks to your banks, payment institutions or sponsor partners, and the permissions stay with them and with you. Rail adapters, ledger design and reconciliation come from us. Licensing, scheme membership and safeguarding arrangements sit with your legal and compliance teams.
How fast can a payout land?
That depends on the rail and the cut-off, so the system reports it rather than promising it. Local instant schemes clear in seconds during scheme hours, wires follow banking windows, card payouts depend on network and issuer. Routing picks a rail against your speed and cost preference per corridor, and the quoted window shows in the status.
What happens when the ledger and the bank disagree?
Automated matching runs against statements and scheme reports, and unmatched items go to an exception queue with candidate matches, ageing and an owner. Tolerance rules absorb fee and currency rounding within limits your finance team sets. Each manual resolution posts its own ledger entry, so the correction itself carries an audit trail.
Can this run beside our existing payment operations?
Yes. The ledger can shadow current flows first, posting entries for payouts the old process still sends, which gives you a comparison against the bank statement before anything moves. Once matching agrees across a few cycles, corridors switch one at a time, with the previous path kept available as a fallback.
Part of Payments
Acceptance, orchestration, and settlement, engineered to stay up and keep approvals high.
Ready to make payments
a product you control?
Tell us where money gets stuck: routing, approvals, reconciliation, a PSP you've outgrown. We'll come back with the build, not a brochure.