Your app marks a payment successful. The processor reports a different amount. A smaller amount lands in the bank. Then the operations team chases that money across three screens and a spreadsheet. FintechBear is building the engine that reconciles those records instead.
Not a bank, money transmitter, or custodian of funds. We compare records and explain the difference — we don't move the money.
An internal system books the gross amount. The processor takes its fee, batches hundreds of payments, and sends the bank a single transfer. A refund lands in the next day's report. A chargeback arrives weeks later. Match on amount alone and you'll pair unrelated transactions — and miss the ones that belong together.
If the references and rules line up, the engine can relate both internal payments to the processor's batch, and the net payout to the bank credit.
But the bank credited $1,460, not $1,470. That's a $10 difference to investigate — and the engine has to show which records and which calculation it came from.
Without an approved tolerance or another explaining rule, a case is opened. Quietly editing the fee later to make the table balance would just hide a difference whose source was never explained.
Illustrative example — not a specific customer or integration
Two sources were imported and normalized, matched on an exact reference rule, and produced 10 matched pairs with four open records. One open record became a case: one person proposed a decision, their own approval was refused, a separate reviewer approved it, and the result was exported — with an audit trail.
A controlled accuracy demonstration — figures shown are not a capacity or performance benchmark
Two things we refuse to compromise: money is represented exactly, and a run can be reproduced. The same canonical data, rule version, and currency metadata must produce the same financial result — regardless of row order or which worker processed it.
float, no double.The file and the records it contains are handled separately — content hash, length, source, and uploader are tied together. Source fields are mapped to one canonical model with versioned rules. payment_ref and transaction_reference only match if you say they mean the same thing.
Composite keys, amount and time tolerances, gross–fee–net relationships, explicit FX policy. “Bounded” is technical: candidate count, group size, and run limits are explicit, so matching stays controlled as volume grows.
Matched, unmatched, inconsistent, duplicate, invalid, ambiguous, conflicted. A difference can be assigned, explained with evidence, and — for critical items — prepared by one person and approved by another.
The Reconciliation Engine is the core. Connector areas describe the data model's reach — a product that can work with these sources, not a claim that every connection is built.
Compare transaction records across two sources, explain the difference, and track how it was handled — with maker-checker and an audit trail.
A connector area for account and payout integration workflows.
A connector area for partner money-movement networks, on the same canonical model.
Electronic money institutions, payment institutions, wallet operators, and businesses working with more than one bank or PSP — anyone who takes financial data from several sources, compares it on a schedule, and burns time investigating the gaps.
Our bar is concrete: when a difference is opened, the source records, the rule applied, and prior actions should be visible in the same review flow. The team shouldn't start the investigation from zero every time.
Tell us where your money's story breaks — the systems, the reports, the gap you keep chasing. We assess scope and fit against your real data.