---
title: "Neobank treasury and reconciliation: matching the ledger, the bank, and the wallet every day"
seoTitle: "Neobank treasury: daily three-way reconciliation"
description: "How a neobank reconciles its ledger with bank and wallet balances every day, why breaks happen, and how funding payouts at send time changes cash flow."
date: "2026-10-15"
updated: "2026-10-15"
category: "payments"
author: "BlindPay Team"
howto:
  name: "How to run a daily three-way reconciliation for a neobank"
  steps:
    - name: "Close the ledger at a fixed cut-off"
      text: "Pick one cut-off time in one time zone and sum every user balance in your ledger at that moment, split by currency and asset."
    - name: "Pull the bank and wallet balances for the same cut-off"
      text: "Export the FBO or operating bank statement and read on-chain balances for every wallet you hold for customers at the same cut-off."
    - name: "List in-flight items"
      text: "Pull every payin and payout that started but did not finish before the cut-off from your provider's API or webhooks."
    - name: "Compute the expected difference"
      text: "Adjust the ledger total by deposits in transit, payouts in processing, fees accrued but not yet charged, and refunds pending."
    - name: "Classify every break"
      text: "Label each remaining difference as timing, fee, FX, duplicate, or unknown, and assign an owner."
    - name: "Clear or escalate within one business day"
      text: "Timing breaks should clear on the next run. Anything older than one day goes to finance and compliance for review."
faq:
  - q: "What is three-way reconciliation for a neobank?"
    a: "It is a daily check that three numbers agree: the sum of all user balances in your ledger, the cash in your bank accounts held for customers, and the stablecoins in wallets held for customers. After adjusting for money in flight, the three should match to the cent. Any difference is a break that someone has to explain."
  - q: "How often should a neobank reconcile?"
    a: "At least daily, at a fixed cut-off time. High-volume neobanks also run intraday checks on payout and deposit events. Daily matters because breaks compound: a missed deposit on Monday becomes a wrong balance, then a wrong payout, then a support ticket. A break caught within 24 hours usually has a clear cause."
  - q: "Do you need to pre-fund payouts?"
    a: "Not with every provider. Pre-funding means parking money with a payout provider before you send. With a stablecoin payout API that funds at send time, the quoted amount is pulled from your wallet when the payout executes. You still keep an operating float in a wallet you control, but no balance sits with the provider in advance."
  - q: "What causes reconciliation breaks?"
    a: "Mostly timing. A deposit has hit the bank but not your ledger, or a payout has left your wallet but not completed. Then fees accrued to an invoice instead of deducted, FX differences between quote and booking, duplicate webhook processing, and refunds that land after the cut-off. Truly unknown breaks are rare and need escalation the same day."
  - q: "What records should a neobank keep for reconciliation?"
    a: "For every money movement: your internal ID, the provider's ID, the quote ID and its locked rate and fees, the status history with timestamps, the bank or blockchain reference, and the ledger entries it produced. Keep the daily reconciliation report itself, signed off by the person who cleared the breaks. Auditors and partner banks ask for both."
---

A neobank reconciles daily by checking that three numbers agree: the sum of user balances in its ledger, the cash in bank accounts held for customers, and the stablecoins in wallets held for customers. After adjusting for money in flight, any gap is a break. With BlindPay, payouts are funded at send time, so no provider balance joins that list.

Treasury in a neobank is mostly bookkeeping that has to be right every single day. The money is spread across a partner bank, wallets, and providers. Your ledger is the only place it adds up. This guide shows how to structure the accounts, run the daily check, and what changes when payouts don't need pre-funding. For the full build path, start with [how to build a neobank in 2026](/resources/more/how-to-build-a-neobank).

**Key takeaways**

- Keep four kinds of balances apart: customer cash, customer stablecoins, operating funds, and fees earned.
- Reconcile at one fixed cut-off, every day, against the bank statement and on-chain balances.
- Most breaks are timing. Track in-flight payins and payouts by status so they explain themselves.
- Pre-funding adds a fourth place money can hide. Funding payouts at send time removes it.

## Which accounts does a neobank treasury need?

Four buckets, kept separate from day one. Mixing them is the fastest way to lose track of whose money is whose.

| Bucket | Holds | Typical location | Reconciled against |
| --- | --- | --- | --- |
| Customer cash | User dollar balances not yet converted | FBO account at a partner bank | Bank statement |
| Customer stablecoins | User balances held as USDC or USDT | Custodial wallets | On-chain balances |
| Operating float | Company money used to fund payouts and timing gaps | Company wallet or bank account | Statement or chain |
| Revenue | Fees and spreads the neobank earned | Company operating account | Fee reports |

If you're still deciding where customer money should sit at all, [where neobanks hold customer funds](/resources/more/where-neobanks-hold-customer-funds) compares FBO accounts, custodial wallets, and customer-controlled wallets.

## What is three-way reconciliation?

It's the daily proof that the ledger matches reality on both sides. The check:

**Ledger total = bank balance + wallet balance + money in flight + fees accrued − items not yet booked**

Each term needs a source:

- **Ledger total:** the sum of every user's balance at the cut-off.
- **Bank balance:** the FBO statement at the same cut-off. Bank cut-offs are fixed by the bank, so align yours to them.
- **Wallet balance:** read directly from the chain for every customer wallet. Don't trust a cached number.
- **Money in flight:** payins that hit the bank but haven't converted, payouts that left a wallet but haven't completed.
- **Fees accrued:** fees owed but not yet charged, such as virtual account deposit fees that bill at month end.

Under [12 CFR 330.5](https://www.law.cornell.edu/cfr/text/12/330.5), the FDIC presumes deposited funds are owned as shown in the bank's account records. For an FBO account, your ledger is what gives those records meaning. A wrong ledger is a compliance problem, not just an accounting one.

## How do you run the daily check?

Six steps, at the same time every day.

1. **Close the ledger at the cut-off.** One time, one time zone. Sum balances by currency and asset.
2. **Pull bank and wallet balances for the same moment.** Statement export for the bank, on-chain reads for wallets.
3. **List in-flight items.** Query your provider for every payin and payout not in a final state. Final states are completed, failed, and refunded.
4. **Compute the expected difference.** Adjust for in-flight items and accrued fees.
5. **Classify every break.** Timing, fee, FX, duplicate, or unknown. Give each one an owner.
6. **Clear or escalate within a business day.** Timing breaks should vanish on the next run. Older breaks go to finance and compliance.

The webhook side matters here. Process each event once, keyed by its ID, and store the full status history. [Stablecoin API webhooks: signature checks, duplicate events, and reconciliation](/resources/more/stablecoin-api-webhooks-reconciliation) covers the patterns.

## Why do breaks happen?

Mostly because money and records move at different speeds.

| Break type | Example | How it clears |
| --- | --- | --- |
| Timing, deposit | ACH credit posted at the bank after your ledger closed | Next day's run |
| Timing, payout | USDC left the wallet, payout still processing | Status reaches completed or refunded |
| Fee | Deposit fee accrued to the monthly invoice, not deducted | Month-end invoice |
| FX | Ledger booked at a different rate than the locked quote | Rebook at the quote rate |
| Duplicate | Same webhook processed twice | Reverse the second entry |
| Refund | Failed payout refunded after the cut-off | Next run, with the refund reference |
| Unknown | No matching record anywhere | Same-day escalation |

US ACH is the main timing source. The Federal Reserve's [FedACH service](https://www.federalreserve.gov/paymentsystems/fedach_about.htm) settles in batches on business days, and [Same Day ACH](https://www.nacha.org/content/same-day-ach) runs in windows within the business day. Stablecoin balances, by contrast, change at any hour. Pick a cut-off that both sides can live with.

For the journal entries behind each line, [how to book a stablecoin payout](/resources/more/stablecoin-payout-accounting-entries) has worked examples.

## How does pre-funding change treasury?

Pre-funding means parking money with a payout provider in advance so it can pay out on your instruction. It adds a fifth balance, one you don't control, that has to be reconciled from the provider's reports.

The working capital formula:

**Capital tied up = average daily payout volume × days of cover the provider requires**

If the provider wants a separate balance per corridor, run the formula once per corridor and add them up.

**Annual cost = capital tied up × your annual cost of capital**

[How much does pre-funding cost?](/resources/more/cost-of-pre-funding-working-capital) breaks this into five cost lines.

## What does the cash flow look like with and without pre-funding?

Illustrative example. A neobank sends 100 payouts a day averaging US$500, so US$50,000 a day. All numbers are invented to show the formula.

| | Pre-funded provider | Funded at send time |
| --- | --- | --- |
| Days of cover the provider asks for | 3 | None |
| Balance parked with the provider | US$150,000 | US$0 |
| Operating float you keep in your own wallet | Small | US$50,000 (one day of volume) |
| Who controls the float | Provider holds the parked balance | You do |
| Balances to reconcile | Ledger, bank, wallet, provider | Ledger, bank, wallet |
| Annual cost at 8% cost of capital | US$12,000 on the parked balance, plus your own float | US$4,000 on your float |

The float doesn't go away when pre-funding does. You still need stablecoins ready to fund payouts. The difference is where they sit: in a wallet you control, counted in your own reconciliation, instead of with a provider. [How much USDC should you hold to fund payouts?](/resources/more/how-much-stablecoin-float-for-payouts) shows how to size it.

## What should go on a treasury checklist?

- Customer cash, customer stablecoins, operating float, and revenue in separate accounts or wallets.
- One daily cut-off, written down, aligned to the bank.
- On-chain balance reads for every wallet, not cached numbers.
- In-flight items pulled by status from your provider every run.
- Every quote's locked rate and fees stored with the payout.
- A break log with owner, age, and resolution.
- A written escalation rule for breaks older than one business day.
- A float target and a refill trigger.
- A monthly review of fees accrued vs invoiced.

## What are the common mistakes?

- **Reconciling weekly.** Breaks pile up and lose their context.
- **Booking FX at a market rate.** Book at the quote rate you executed. That's the rate your user saw.
- **Counting a payout as done when it leaves the wallet.** It's done when it reaches a final status.
- **Ignoring accrued fees.** Small deposit fees that bill monthly show up as a steady drift.
- **Letting the float live in a customer wallet.** Company money and customer money stay apart.

## How BlindPay fits

BlindPay keeps the provider side of your reconciliation short. Payouts fund at send time: the quote locks the rate and fees for 5 minutes, and when the payout executes, the quoted stablecoin amount is pulled from the funding wallet. There's no balance parked with BlindPay in advance. See [what "no pre-funding" means in a stablecoin API](/resources/more/no-pre-funding-stablecoin-payouts).

Each [payout](/docs/payouts) moves through processing to completed, failed, or refunded, and each status change arrives as a signed webhook. On [virtual accounts](/docs/virtual-accounts), each deposit creates a payin with its fee shown in one of two fields: deposits below US$100.00 accrue the fee to your monthly invoice, and deposits of US$100.00 or more have it deducted at the time of the transaction. That split is exactly the kind of line your fee reconciliation needs to know about.

BlindPay operates as a non-custodial payment processor for payout flows from customer-controlled wallets. Optional managed wallets (beta) are custodial when you choose that path.

## What to do next

Write down your cut-off time and your four treasury buckets this week, then run one manual three-way reconciliation against a development instance. The [webhooks events reference](/docs/learn/webhooks-events) lists every payin and payout status you'll need to track money in flight.