The PSP Model: One Balance, Local Endpoints at Both Ends
Part I · PSP Architecture (Chapters 1–5) Builds on: Payment Systems, Chapter 13 (correspondent banks; SWIFT carries messages), Chapter 18 (four sources of cross-border cost), Chapter 19 (Wise's local-in, local-out model), Chapter 20 (where PSPs sit in the industry) New concepts in this chapter: balance core, pay-in endpoint, payout endpoint, one core with many endpoints
1. With one bank account, every collection and payout crosses a border¶
Meet the company we will follow throughout the course.
StarMap is a design software business registered in Singapore. Most of its customers are in Europe; its suppliers are spread around the world. Every month, it needs to do three things:
- Collect a €1,000 subscription payment from Müller Design in Germany.
- Pay £800 to a freelance illustrator in the UK.
- Keep the remainder for next month.
These sound routine. But if StarMap has only a Singapore bank account, both the collection and the payout become cross-border transfers. The money it retains sits in Singapore until another cross-border payment is needed.
Collecting: Müller sends €1,000 from its German bank to StarMap's Singapore account. As the chapter on no global central bank explains, the two central-bank ledgers are not connected. Correspondent banks — banks that collect and pay locally for other banks — relay the payment from the German bank through one or two intermediaries to Singapore. SWIFT carries the messages; the money is recorded in correspondent accounts at each step.
Paying: StarMap sends £800 from Singapore to the illustrator's UK account. The relay happens again, this time outbound from Singapore and in sterling.
Both transfers encounter the four sources of cross-border cost: FX spreads, intermediary fees, prefunded liquidity and compliance checks. Each also leaves three uncertainties:
| Uncertainty | Why it arises |
|---|---|
| How much will arrive? | Intermediaries deduct fees under their own rules; the sender does not know all the deductions at initiation |
| When will it arrive? | Each bank has its own cutoffs, time zone and holidays |
| Where is it now? | A message has a tracking reference, but the sender cannot see which bank's ledger currently holds the funds |
StarMap's finance team spends days reconciling these payments each month. Occasionally the illustrator complains that £20 is missing.
2. Replace two cross-border transfers with two local transfers¶
The Wise model introduced an idea: a cross-border payment can be delivered without sending that individual payment across the border. A provider with local accounts at both ends can collect locally in one country and pay locally in the other, connecting the two on its own ledger.
A payment service provider, or PSP, turns this approach into a business product. StarMap opens an account with a PSP and uses it for the same three tasks.
Collecting: the PSP gives StarMap German collection details: an IBAN beginning with DE. An IBAN is the bank-account format used across Europe; its first two letters identify the country. Müller makes a local SEPA transfer, the standard euro bank transfer, just as it would pay a nearby company. In this example, it arrives by the next day with no intermediary deduction. The money lands in the PSP's German bank account. The PSP records a €1,000 increase in StarMap's balance.
Paying: StarMap requests a payout to the UK illustrator. The PSP already has sterling in the UK and sends £800 over Faster Payments, or FPS, the UK's domestic instant-transfer system. It arrives in seconds as £800, rather than £780. StarMap holds euros but pays sterling, so the PSP quotes an exchange rate and StarMap accepts it: in our example, £800 costs €944. The PSP reduces StarMap's balance by €944. How the PSP later replenishes its German and UK accounts is covered in payout endpoints.
Keeping the remainder: the retained money is represented by StarMap's balance on the PSP's ledger. That is the number StarMap sees in its app.
Two cross-border transfers have become one German domestic transfer and one UK domestic transfer, connected by a single PSP ledger.
3. Balance core, pay-in endpoint and payout endpoint¶
The product has three components:
| Component | What it does | In StarMap's example |
|---|---|---|
| Balance core | Holds customer funds, records each customer's entitlement and displays a balance | StarMap's balance on the PSP ledger and the real funds backing it |
| Pay-in endpoint | Collects over a country's local rails and identifies the customer entitled to the receipt | The DE collection account number and the determination that the €1,000 belongs to StarMap |
| Payout endpoint | Pays over a country's local rails and reports the result to the core | The PSP's UK sterling funds and the FPS transfer |
We will use the industry terms pay-in for collections and payout for outbound payments throughout the course.
The relationship fits into one sentence:
A PSP provides its customers with one balance core, connected to pay-in and payout endpoints across countries.
One component is different: there is one balance core, while there can be many endpoints.
Why one core? A balance must come from a single coherent ledger. StarMap's German collections, UK payouts and US collections must all feed that ledger. It may have separate euro, sterling and dollar accounts within it, but it provides one consistent record. Otherwise StarMap has several balances that cannot be reconciled, and finance cannot establish how much it owns. Neobank anatomy describes Synapse, an intermediary that kept records for dozens of fintechs. When it failed, money remained at partner banks, but ownership records could not establish each customer's share, leaving roughly 100,000 users unable to access their money. The failure was in what we call the balance core.
Why many endpoints? Domestic rails operate separately in each country. To offer local collections and payouts in another country, a PSP adds endpoints there while retaining the core. Product claims such as "local collections in X countries and payouts in Y countries" describe that endpoint coverage.
4. What differs from a SWIFT multi-hop transfer?¶
The structural difference is who takes responsibility for the middle of the payment chain.
| Dimension | SWIFT multi-hop model | PSP model |
|---|---|---|
| Ledgers along the way | One per hop, typically two to four, held by independent banks | One PSP ledger |
| Cross-border movement | The customer's payment proceeds across borders in stages | The customer payment is fulfilled by local transfers at both ends |
| Exchange rate | The sending or receiving bank uses its rate; the sender often sees the applied rate afterward | The PSP quotes a rate for the customer to approve |
| Amount received | Uncertain at initiation in this example | Agreed at initiation |
| Status visibility | The sender sees a message-tracking reference | The PSP records the status of each leg in its own system |
| Prerequisites | The banks at both ends need correspondent relationships | The PSP needs local accounts and rail access at both ends, plus permission to hold customer balances |
The final row explains the tradeoff. The PSP takes on work previously distributed across several banks:
- It must place money in each country in advance. Sterling must already be in the UK account when StarMap pays.
- It must be permitted to hold customer balances, which generally requires a licence.
- It must reconcile the German euro receipt and the UK sterling payout itself. No bank does that entire job for it.
The first responsibility belongs to payout endpoints, the second to the balance core, and the third spans all three components.
5. Licensing and engineering: permission to operate, and the ability to do it correctly¶
These responsibilities fall into two different categories: licensing and engineering requirements.
Licensing requirements determine who is allowed to perform an activity. Holding an e-money balance in the EU requires an electronic money institution, or EMI, licence; paying in one's own name over UK domestic rails requires the appropriate FPS access. Without the relevant permission, the service cannot start. With it, the provider has permission to proceed.
Engineering requirements determine whether the provider performs the activity correctly. Of the 137 payments arriving in the German account today, which belongs to StarMap? Did the £800 UK payment arrive, return or become stuck? Do aggregate customer balances reconcile to funds in bank accounts across countries? A licence does not solve these problems. Ledgers and reconciliation calls this the skeleton of a payment system.
Each component has both kinds of requirements:
| Licensing requirements | Engineering requirements | |
|---|---|---|
| Balance core | Permission to hold customer funds; safeguarding | One authoritative ledger; daily reconciliation of ledger totals to safeguarded funds |
| Pay-in endpoint | Permission to collect locally; local clearing access | Identify each receipt; distinguish receipt from availability; handle returns |
| Payout endpoint | Permission to pay locally; local clearing access | Prefund local currency; track payment states; handle failures and returns |
This table sets up the next three chapters. Each opens one component, covering its licensing requirements and then its engineering requirements.
6. The questions this raises¶
StarMap opens the app and sees €1,000. Who records that number? In which bank account are the euros held? If the PSP fails tomorrow, can StarMap recover them?
All three questions concern the balance core. The next chapter starts with who owes StarMap the €1,000.
7. Self-check questions¶
- After StarMap switches to the PSP, does Müller's €1,000 ever leave Germany? Where does the illustrator's £800 come from?
- A PSP advertises local collections in 60 countries and payouts in 120. Using the three-component model, how many cores, pay-in endpoints and payout endpoints does it have?
- Classify these as licensing or engineering requirements: (a) holding customer balances in Singapore requires the relevant MPI permission; (b) each of today's 137 German receipts must be assigned to the correct customer.
8. Answers¶
Try answering before reading on.
The euros stay in Germany, moving from Müller's German bank account to the PSP's German account. The illustrator receives sterling that the PSP prefunded in its UK account. Those pounds are separate from Müller's euros. The local transfers are connected by the increase and decrease in StarMap's PSP ledger balance.
One balance core, 60 pay-in endpoints and 120 payout endpoints in this simplified country-based count. All collections and payouts must update one coherent ledger. More precisely, endpoints are counted by country and rail. Payout coverage often exceeds collection coverage: payouts require local funds and rail access, while collections also require the ability to allocate local collection details to customers, as pay-in endpoints explains.
(a) is a licensing requirement: permission to hold customer balances. (b) is an engineering requirement: correctly identifying funds. A licence does not prevent a misidentified payment from corrupting StarMap's balance.
Previous: (none — this is the starting point) Next: Chapter 2 · The Balance Core: Who Owes the Customer, and How Is Ownership Proven?