Bank reconciliation automation, for an FBO account, means software that collects the bank's records and each fintech partner's customer file every morning, pairs the entries, explains the differences with evidence and leaves people to decide and sign. The FBO account is the custodial deposit account a sponsor bank holds for a fintech's customers, and its reconciliation is harder than a corporate bank rec because the two sides live in at least five systems: the core banking system, the payments hub, the card processor, the partner's file and the program agreement. The right automation reads each of those where it already is and replaces none of them. Botminds' FBO Reconciliation is built that way: seven agents beside the existing stack, a recompute that can block a filing, and a write-back limited to adjusting entries a Controller has approved.
The examples come from a fictional sample bank running the solution: Tessaly Community Bank, six fintech partners, 412,000 end users. Rules and guidance are linked where they appear.
FBO Reconciliation's stack map: read five systems, replace none, write back only approved entries
Read in place, never replaced
Seven agents, overnight
People sign; one write-back
Can bank reconciliation be automated for an FBO account?
Bank reconciliation can be automated for an FBO account up to the point where someone has to vouch for the result. Collecting files, checking that they are complete, pairing entries and drafting the explanation of each difference are mechanical and can run overnight across every row. Deciding that a difference is explained, telling a partner to fund a negative balance and signing the day's attestation are judgments, and on a custodial account they belong to named people with a second person checking.
The difference from a corporate bank reconciliation is volume and number of sources. A business reconciles one statement against its cash book once a month. A sponsor bank reconciles each FBO account against a partner file that can hold hundreds of thousands of balances, every business day, with the money moving through systems on different clocks. At the sample bank one partner alone sent 842,318 entries for a single day. That is the case for automation, and it is also why the design of the automation matters: a reconciliation that is fast but cannot show its work has only moved the risk.
What bank reconciliation automation software usually does, and what FBO accounts add
Most bank reconciliation automation software matches transactions on a bank statement to entries in a set of books by amount, date and reference, and queues what does not match. An FBO reconciliation needs that and four things more: several bank-side sources rather than one statement, a third party's books on the other side, a check on every individual balance, and an evidence trail strong enough for a regulator rather than an auditor's sample.
Typical bank reconciliation automation, and what an FBO account adds
Typical bank reconciliation automation: One bank statement or feed against one cash account
What an FBO reconciliation also needs: Core postings, payments hub files, card settlement and each partner's file, with control totals checked on arrival
Typical bank reconciliation automation: Rules on amount, date and reference
What an FBO reconciliation also needs: Pairing of partner entries to the bank record behind them, with a confidence floor and no forced matches
Typical bank reconciliation automation: A queue for the accountant
What an FBO reconciliation also needs: Each difference explained with its records and an expected clear time, then checked the next day
Typical bank reconciliation automation: Rarely below the transaction
What an FBO reconciliation also needs: Every end user: negatives, duplicates, missing owners, missing fields, ownership codes
Typical bank reconciliation automation: Reviewer signs the reconciliation
What an FBO reconciliation also needs: An independent recompute of both totals, then a preparer and a different checker
Typical bank reconciliation automation: Last month's workpaper
What an FBO reconciliation also needs: Any business day rebuilt from the attested snapshot, in the FDIC's proposed layout
How to automate bank reconciliation without replacing the core
To automate bank reconciliation without replacing the core, read every source where it already lives, never alter it, and keep the only write-back to entries a person has approved. Banks have good reasons to leave the core alone: it is the deposit system of record, it is expensive and slow to change, and a reconciliation that edits the system it reconciles has nothing left to prove. The same logic applies to the partner's books. If a partner file is wrong, the partner corrects it in the next file; the bank's job is to find the error and record the case.
Five design rules follow, and they are the ones to test in any product. First, read-only connections to the core, payments hub and card processor, with the files the bank already produces for its own operations. Second, partner files by the same secure transfer the partner already uses, checked for arrival, control totals and format before anything is loaded. Third, no edits to any source, by any agent. Fourth, the totals recomputed independently of the matching, so that an error in pairing cannot hide in the check. Fifth, a single write-back: adjusting entries to the general ledger, each proposed by one person and approved by another.
The OCC's internal-control booklet gives the reason for the fourth and fifth rules in its own terms. It expects accounts to be "reconciled continually, independently, and in a timely manner" and outstanding items "resolved and cleared" (OCC, Internal Control). Automation that recomputes on a separate path and leaves approval to people is how that independence survives when software does most of the work. Why the agent that explains a difference never checks the totals takes that argument further.
The bank reconciliation automation process, step by step
The bank reconciliation automation process for one FBO account runs in six steps, four by agents and two by people. At the sample bank the agents ran between 5:00 and 7:40 am; the analysts started on the exceptions after 9:00.
One partner's day in FBO Reconciliation, from the files arriving to the attestation
Agent
IntakeReads the core's FBO balance at the 9:00 pm close, the payments hub's ACH and wire files, card settlement and the partner's file, due at 5:00 am; checks control totals and format.
Never: loads a file that fails its checks; a late file opens a case and an escalation instead.
Agent
MatchingPairs each partner entry with the bank record behind it.
Never: forces a pair below 0.95.
Agent
BreakWalks the difference to zero, step by step, each step with its records and an expected clear time.
Never: calls a difference explained without a record.
Agent
Recompute and end-user checksRebuilds both totals from raw files on a separate path, checks every end user and drafts the attestation and any partner notice.
Never: signs, files, sends or moves money.
A person decides
PreparerReviews the exceptions, gives each a reason code and signs as preparer.
A person decides
CheckerOpens the same records, checks and files the attestation.
Never: files their own work.
The order matters more than the speed. Intake comes first so that nothing is matched against a file that is incomplete. The recompute comes after the explanation so that it can disagree with it. And people come last, with the full trail in front of them, rather than in the middle of a spreadsheet trying to find the records.
The contingency test: could you reconcile if the partner went dark?
The test of a reconciliation stack is not the ordinary morning but the morning the partner's system is gone. Synapse showed what that looks like. The FDIC's account of the bankruptcy notes that "Court filings state that the trustee had difficulty obtaining access to Synapse's data, due in part to Synapse's termination of its employees, including employees who held credentials necessary to access systems and databases where the relevant records were stored" (FDIC, 89 FR 80135).
The FDIC's 2024 proposal, still pending, lists what a bank relying on a third party's records might keep in reserve. Its examples are a useful design brief for any automation, rule or no rule.
"(1) storing copies of prior daily or weekly account balances and beneficial ownership balances internally at the IDI, or at another location independent of the third party; (2) establishing legal authority and technological capability for the IDI to access daily transaction records associated with the custodial deposit account directly from payment networks, processors, or service providers used by the third party; and (3) maintaining at the IDI sufficient trained staff, technical systems, and other resources to process transaction records necessary for the IDI to reconcile and establish accurate records for ownership interests in the custodial deposit account, in the event the third party is disrupted." FDIC, Recordkeeping for Custodial Accounts, proposed rule, 89 FR 80135, October 2, 2024
Five questions that show whether a reconciliation stack survives a partner's failure
- Does the bank hold every end user's balance for every business day, inside the bank?
Not the partner's latest export, but a dated, attested snapshot the bank controls.
- Can the bank read the transactions without the partner?
The core, payments hub and card processor files exist at the bank; the reconciliation should be built on them, not on the partner's summary.
- Can the last good day be rebuilt in minutes?
Every balance, every ownership code, with who prepared and checked it.
- Do the bank's own people know how to run it?
If the reconciliation is a partner's report the bank only reads, the skill to reconcile is not in the building.
- Does the contract give the bank access to data held by others?
The proposal would require the contract to assign those rights to the bank; check whether yours does.
The bank regulators asked the industry the same question from the other end in their 2024 request for information on bank-fintech arrangements: "In the context of bank-fintech arrangements, how are deposit accounts usually titled? Describe the range of practices reconciling bank deposit account records with the fintechs' records" (OCC, Federal Reserve and FDIC, 89 FR 61577). The way the accounts are titled and who keeps which books shapes every daily break; how the FBO account structure decides the breaks works through the options.
Reconciliation software for audit: what the trail must hold
Reconciliation software for audit has to let an examiner or internal auditor re-perform any step: see what the software read, open the exact passage behind each claim, and see who did what and when. On an FBO account the bar is higher than a month-end workpaper, because the question is often about one end user on one day. The branch side of the same work, ATM and teller cash, has its own guide to reconciliation software for banks.
Every number in FBO Reconciliation opens the record behind it
Three properties make the trail usable. Every value and every agent statement carries a citation that opens the source passage. Every action, from opening a source to approving an entry, is recorded with the person, time and reason. And the day's state is kept as a snapshot, so a later question about a past day is answered from what was attested rather than from a rebuild. Names and tax IDs stay masked unless a user gives a reason to show them, which also goes on the trail.
Approvals in FBO Reconciliation: every entry made by one person and checked by another
A pilot on your own files: four weeks, four questions
The way to judge bank reconciliation automation is to run it on your own closed days, where you already know the answer. The plan below is our suggestion for a first month; the weeks are a guide, and the pace depends on how quickly partner files and read access can be arranged.
A four-week pilot on a sample of your own FBO accounts and partner files
- Read-only access to filesweek 1
- Replay closed daysweek 2
- Run beside the deskweek 3
- Compare and decideweek 4
Each week answers one question. Can the stack read your core, payments and card files and each partner's file without changing anything? On days you have already closed, does it find the breaks your analysts found, and any they missed? Running beside the live desk, does it have the morning's differences walked down before the analysts start? And at the end, would your checker and your examiner accept its trail? A product that cannot be tested this way is asking to be trusted rather than checked.
Where FBO Reconciliation fits in the stack, and where it does not
FBO Reconciliation fits beside the systems an FBO account already runs on: the core, the payments hub, the card processor, the partner files, contract management and the general ledger. It is the layer that reads them, reconciles them and keeps the evidence. It does not replace the core's deposit system of record, the partner's books, the bank's general ledger or its case management for other work, and it does not move money: a funding from a partner's reserve is proposed by one person and approved by the Controller.
It is also not the right tool for every reconciliation in the bank. Nostro accounts, branch cash and corporate clients' bank statements have their own tools and their own rules. The solution is for custodial deposit accounts held for third parties' customers, where the other side of the reconciliation is someone else's books. What that daily work costs a bank, by the FDIC's own estimate, is set out separately. To see it on a sample of your own FBO accounts and partner files, start from FBO Reconciliation.
Questions people ask
What is account reconciliation automation?
It is software that gathers a balance and its supporting detail, matches them, explains or queues the differences and prepares the reconciliation for review, so that people spend their time on exceptions rather than on collecting and matching. On an FBO account it extends to every customer balance behind the account, not only to the account's transactions.
Is bank statement reconciliation automation the same thing?
It is the narrower case: matching a bank statement or feed to an entity's own books. An FBO reconciliation runs the other way round, from the bank's side, and adds a third party's customer file, card settlement and payments files, and a check on every individual balance.
Does automation need direct access to the fintech partner's systems?
Not for the daily work: the partner's file arrives by secure file transfer, and the bank-side records are already in the bank. The FDIC's 2024 proposal would go further and require direct, continuing access to the partner's beneficial-ownership records, including if the partner fails, which is a contract term as much as a technical one.
What should never be automated in an FBO reconciliation?
Signing or filing the attestation, sending a notice to a partner, moving money between a partner's reserve and the custodial account, approving adjusting entries and deciding what an unexplained difference is. Each is a judgment with consequences for customers, and each should be made by one person and checked by another.
How do you test reconciliation software before buying it?
Replay days you have already closed. Give the software the same files your desk had, compare every break it explains with what your analysts concluded, and look for breaks either side missed. Then run it beside the live desk for a few weeks before relying on it.