The Balance Core: Who Owes the Customer, and How Is Ownership Proven?

Part I · PSP Architecture (Chapters 1–5) Builds on: Payment Systems, Chapter 3 (money hierarchy and liabilities), Chapter 22 (FBO accounts and Synapse), Chapter 24 (three levels of licensing), Chapter 25 (double-entry bookkeeping and reconciliation) New concepts in this chapter: safeguarded account, authoritative and mirror ledgers, four balance states, own licence and licensed partner

1. The question from the previous chapter¶

The previous chapter ended with StarMap's €1,000 app balance. Who records it, where is the money, and can StarMap recover it if the PSP fails?

The hierarchy of money gives us two questions: Who owes you? What backs that promise, and where are the reserves?

There are two layers:

• The PSP owes StarMap €1,000. StarMap's balance is a liability of the PSP.
• To meet that liability, the PSP holds Müller's €1,000 in an account at a German bank. That bank owes the PSP €1,000.

StarMap's balance therefore sits one layer below a bank deposit. A deposit means "the bank owes you"; this balance means "the PSP owes you, and the PSP holds a claim on a bank." The extra layer introduces another credit relationship and another possible point of failure.

The balance core's two sets of requirements address that layer. Licensing determines who may owe customers money and where the backing funds must be held. Engineering determines whether the records can prove, at any time, who owns each unit of value.

2. Licensing requirements: who may owe customers money?¶

A PSP receives customer money, holds it in an account in its own name, and lets the customer instruct payments. That resembles taking deposits. For the regulatory distinction used here, one difference is central: a bank can lend out deposits; a PSP cannot lend out the customer funds it holds for payments.

The compliance skeleton groups permissions into three levels according to how deeply a provider handles money. The lightest only transmits instructions; the heaviest is banking, including lending deposits. A balance core sits in the middle: it may hold customer funds but may not use them as its own. Jurisdictions name and regulate that category differently:

The names differ, but the recurring principle is safeguarding: customer money must be protected separately from the PSP's own funds. Under the account-based arrangement used in this course, it goes into a dedicated account identified as holding customer funds. On the PSP's failure, those funds are reserved for repayment to customers according to the records, rather than for the PSP's general creditors. We call this a safeguarded account.

StarMap's recovery therefore depends on two things: the funds must have been safeguarded, and the records must establish that €1,000 belongs to StarMap. Licensing addresses the first; engineering addresses the second.

Payment Licences and Players covers individual permissions and application requirements across ten jurisdictions. For this course, retain the following distinction:

To assess whether a provider may hold customer balances, examine its permissions. To assess where the backing money must be held, examine the safeguarding rules.

Without your own licence: use a licensed partner

A licence can take one to two years to obtain and requires capital and a compliance team. Many PSPs start by partnering with an already licensed institution for the balance core.

This resembles the arrangement in neobank anatomy. The licensed institution — an EMI, or a bank in the US — opens an omnibus account holding funds for all the PSP's customers. The PSP keeps records of each customer's share. Specialist providers offer this arrangement in the UK, EU and Singapore.

In the partner arrangement described here, the licensed institution owes the customer the money. StarMap's balance is legally a claim against the EMI, usually stated in the account agreement. The partner maintains the authoritative ledger; the PSP's record mirrors it.

The third row follows from the first: the authoritative record belongs to the party legally liable to the customer. The PSP must reconcile its mirror ledger with the partner every day. Otherwise, the balance StarMap sees and the balance the partner recognizes may differ.

3. Engineering requirements: one authoritative ledger, reconciled daily¶

Obtaining a licence or using a licensed partner establishes permission. The engineering question remains: how can the system prove who owns every unit of value?

What the ledger records

Suppose the PSP has three customers and €10,000 in its safeguarded account. Its records need at least this detail:

Each state represents a different situation:

The distinction matters because each state corresponds to a different external fact. The pending €500 may be returned. A failed payout may release the reserved €600. The frozen €200 requires compliance clearance. One undifferentiated balance cannot explain these events.

Reconciliation: ledger totals must match safeguarded funds

The €10,000 total must reconcile to the bank statement for the safeguarded account. This comparison is performed at least daily.

Discrepancies generally fall into three categories:

Every discrepancy must be resolved. An approximate match is insufficient. In the Synapse case, funds remained at banks but the records could not establish each customer's share, leaving roughly 100,000 users without access. The funds were in omnibus accounts at licensed banks — called FBO accounts in the US — but the ownership records failed. That is an engineering failure within the model used here.

Multiple currencies: one core, separate currency records

StarMap collects euros and pays sterling. The core therefore needs both euro and sterling balances. In our example, there is a safeguarded account for each currency and a separate currency column in the ledger. Each currency is reconciled separately. StarMap's balance is a set of amounts: euros, pounds, dollars and so on.

Customer FX reduces StarMap's euro balance and increases its sterling balance. The PSP must also obtain the corresponding sterling and move the backing funds between its currency accounts. That involves its own FX and funding operations, examined in payout endpoints.

4. Comparing the two sets of requirements¶

A licensing failure prevents the activity. An engineering failure means the activity happens incorrectly, with consequences for customers. This is why each component is examined through both lenses.

5. The questions this raises¶

The core records €1,000 available to StarMap. How did it establish that amount? On the day Müller paid, 137 receipts reached the PSP's German bank account. How did the PSP identify StarMap's payment? Does receipt at the bank immediately make the money available to StarMap?

These are pay-in questions. The next chapter starts by identifying the owners of those 137 receipts.

6. Self-check questions¶

1. StarMap's PSP uses a UK EMI as its licensed partner. Whose liability is StarMap's €1,000 balance, and which party's ledger is authoritative?
2. The ledger totals €10,000 but the safeguarded bank account has €10,300. What might the extra €300 represent, and how should it be handled?
3. Why separate available and reserved funds instead of immediately deducting a payout when it is initiated?

7. Answers¶

Try answering before reading on.

1. It is the UK EMI's liability in this arrangement. StarMap signs the EMI's e-money agreement; the PSP distributes the service. The EMI holds the authoritative ledger and the PSP keeps a mirror. The displayed balance is reliable only if the mirror reconciles to the EMI's records daily.

2. A likely explanation is an unidentified receipt. Record the €300 in an unidentified-receipts account so the ledger accounts for the full €10,300, then investigate the payer details. Once identified, assign it to the customer's pending or available balance. Extra money cannot simply be ignored or assigned to a guessed customer.

3. A payout takes time and can fail. Until completion, the customer must be prevented from spending the same amount again, but the payout is not yet confirmed as paid. Reserved funds capture that intermediate state. Success completes the deduction; failure releases the reservation. The ledger thus records the reason for each change rather than treating a failed payout as an unexplained increase in funds.

Previous: Chapter 1 · The PSP Model: One Balance, Local Endpoints at Both Ends Next: Chapter 3 · Pay-in Endpoints: Identifying Incoming Money