Putting It Together: A Cross-Border Payment from Start to Finish
Part I · PSP Architecture (Chapters 1–5) Builds on: Chapter 1–Chapter 4 of this course; Payment Systems, Chapter 19 (the Wise model), Chapter 21 (Wise and Airwallex compared) New concepts in this chapter: funds track and ledger track, four PSP forms
1. The question from the previous chapter¶
We have examined the balance core, pay-in endpoints and payout endpoints separately. What happens when all three work together, from Müller's payment to the illustrator's receipt?
We will follow the complete transaction, combine the requirements and build-or-partner choices, then apply the framework to real companies.
2. Follow the payment from start to finish¶
First, distinguish the three kinds of records:
| Record | Where it is kept | What it records |
|---|---|---|
| Bank accounts | The PSP's German and UK accounts: customer funds in safeguarded accounts, proprietary funds in its own operating accounts | Actual funds |
| Endpoint records | Pay-in and payout systems | The state of each receipt and payout |
| Core ledger | Balance core | StarMap's available, pending and reserved amounts by currency |
Initially, the German safeguarded account contains €50,000 belonging to other customers. The PSP's own German account is empty; its own UK account holds £30,000 of prefunding. StarMap's balance is zero.
| Time | Event | German safeguarded account (€; customer funds) | PSP's own German account (€) | PSP's own UK account (£; prefunding) | Endpoint record | StarMap's core ledger balance (€) |
|---|---|---|---|---|---|---|
| Mon 15:00 | Müller initiates a €1,000 SEPA transfer to StarMap's virtual IBAN | 50,000 | 0 | 30,000 | None | Available 0 |
| Tue 08:10 | German bank credits the funds and reports virtual account …0042 | 51,000 | 0 | 30,000 | Pay-in: received, identified as StarMap's | Available 0 |
| Tue 08:11 | Pay-in confirms availability following settled SEPA receipt | 51,000 | 0 | 30,000 | Pay-in: available | Available 1,000 |
| Tue 10:30 | StarMap requests £800; accepts the €944 quote; beneficiary checks pass | 51,000 | 0 | 30,000 | Payout: accepted | Available 56; reserved 944 |
| Tue 10:30 | Endpoint sends £800 from the sterling pool over FPS | 51,000 | 0 | 29,200 | Payout: sent | Available 56; reserved 944 |
| Tue 10:30 | FPS confirms beneficiary credit | 51,000 | 0 | 29,200 | Payout: credited | Available 56; reserved 0 |
| Tue 18:00 | Daily reconciliation transfers €944 no longer owed to customers out of safeguarding | 50,056 | 944 | 29,200 | None | Unchanged |
| Fri 17:00 | Treasury converts and transfers net surplus euros from Germany to replenish UK sterling | 50,056 | Decreases by the net transfer | Increases by the net transfer | None | Unchanged |
Read the table along two tracks.
The funds track is the three bank-account columns. Actual funds move four times: €1,000 arrives in German safeguarding; £800 of PSP prefunding leaves the UK account; €944 moves from safeguarding to the PSP's own German account; and the PSP rebalances its own funds from Germany to the UK. The first three movements are domestic. Only the fourth crosses a border, using the PSP's own money.
The ledger track is the final column. StarMap moves from zero to €1,000, then to €56 available plus €944 reserved, and finally to €56 available. Each customer-balance change follows an endpoint event; the core does not change balances without a reason.
The relationship is:
Endpoints operate the funds track; the core records the ledger track. Endpoint state changes determine the corresponding ledger actions.
This gives a practical check: every customer-ledger change must trace to an identifiable endpoint event and state. An unexplained change is a posting error. Three-way reconciliation tests that connection.
The 18:00 row makes the ownership boundary visible. After the 10:30 payout, all €1,000 still physically sits in the German safeguarded account, but only €56 remains owed to StarMap. The €944 spent through the PSP's sterling prefunding now belongs to the PSP. Under the balance core arrangement, reconciliation releases that amount to the PSP's own account; Friday's treasury transfer then replenishes sterling. The ownership boundary changes with the completed payment. The ledger recognizes it immediately; bank-account placement catches up through the reconciliation transfer. This is one reason reconciliation must happen daily.
3. All three components and both sets of requirements¶
The PSP model previewed this table. We can now explain every cell:
| Licensing requirements | Engineering requirements | |
|---|---|---|
| Balance core | Permissions to hold customer balances, such as EMI, MPI or MTL permissions; safeguarding | Authoritative records by customer, currency and state; daily reconciliation to safeguarded funds |
| Pay-in endpoint | Local collection permission; direct or indirect clearing access | Virtual-account identification; rail-specific availability; automatic ledger handling for returns |
| Payout endpoint | Local payout permission; clearing access; beneficiary screening obligations | Beneficiary validation; prefunded currency; failure and return states; separate customer FX from treasury rebalancing |
Across each row, permission precedes correct execution. Down the table, regulated services can be sourced from partners, while responsibility for operating the customer product correctly remains.
4. Four PSP forms, from building everything to supplying endpoints¶
Combining the build-or-partner decisions produces four broad forms:
| Form | Balance core | Pay-in endpoints | Payout endpoints | Fixed cost | Per-payment cost | Control over status |
|---|---|---|---|---|---|---|
| Builds extensively in-house | Own licences across markets | Direct access and own collection identifiers in major markets | Own pools and FX operations | Highest | Lowest | Strongest |
| Own core, mixed endpoints | Own licences | Direct in a few markets, indirect in most | Own major-currency pools; networks for smaller markets | High | Medium | Strong in major markets |
| Partner core, sourced endpoints | Licensed partner | Sponsor banks or BaaS throughout | Payout networks throughout | Low | High | Limited to partner reports |
| Endpoint supplier, without a customer balance core | No enterprise-facing balance | Sells collection-account capabilities to other PSPs | Sells payout-network access to other PSPs | High | Not applicable: it charges other providers per payment | Strong, but serves PSPs rather than enterprises |
Building turns costs into fixed costs and gives the PSP more control. Sourcing turns costs into per-payment charges and leaves more control with partners. Sourcing is cheaper at low volume; building becomes cheaper once volume spreads the fixed cost sufficiently. The threshold depends on volume and margin.
The fourth form serves other PSPs rather than companies like StarMap. Sponsor banks in pay-in endpoints and payout networks in payout endpoints supply the capabilities that the other three forms can buy.
5. Apply the framework to Wise, Airwallex and Nium¶
A useful framework should explain real companies. This comparison uses public information available by mid-2026 and focuses on structure. Wise in Payment Licences and Players provides the licence detail.
| Wise | Airwallex | Nium | |
|---|---|---|---|
| Customers | Individuals and small businesses | Platforms and small businesses | Primarily PSPs, banks and platforms: B2B2X |
| Balance core | Own permissions, including UK EMI, Belgian PI, Singapore MPI and US state MTLs | Own permissions across Singapore, Australia, Hong Kong, UK, EU, US and other markets | Own permissions across Singapore, UK, EU, US and other markets |
| Pay-in endpoints | UK FPS direct access and a Bank of England settlement account since 2018; Hungarian central-bank account; SEPA access through the Bank of Lithuania gateway; indirect or local-partner access elsewhere | Own licences in major markets, with mainly indirect clearing access | Own licences in major markets, with mainly indirect clearing access |
| Payout endpoints | Own pools in major corridors | Own major-currency operations, partners for smaller markets | Itself a payout network covering over 100 countries |
| Closest form | Extensive in-house infrastructure; also sells endpoints through Wise Platform | Own core, mixed endpoints | Own core, mixed endpoints, while also supplying other providers |
In the language of the PSP model:
- Their common feature is an owned balance core. Each has invested in its own regulated foundation as it scaled beyond a partner-dependent starting model.
- Endpoint depth differs. Wise participates directly in several markets where others mainly use banks. Its remittance volume in those corridors helps spread the fixed costs of direct access.
- Their customers differ. Nium supplies endpoints to other PSPs, combining the second and fourth forms. The Wise and Airwallex comparison starts by asking whom a payment company sells to. The same architecture produces different products for individuals, businesses and other providers.
6. The questions this raises¶
We now have the basic architecture: one balance core, many pay-in and payout endpoints, two sets of requirements for each, and build-or-partner choices throughout.
StarMap still has unmet needs. Some European customers want to pay by card; Southeast Asian customers prefer QR payments; employees need cards for travel expenses. Basic transfer endpoints do not provide these capabilities. A bank-transfer pay-in receives money pushed by a payer; card acceptance involves a merchant-initiated pull. A transfer payout does not itself issue a card.
The next chapter examines the first extension: how acquiring differs from supplying a collection account.
7. Self-check questions¶
- Between the 10:30 payout confirmation and 18:00 reconciliation, how much of the €1,000 in the German safeguarded account belongs to StarMap, and how much to the PSP? When do the ledger and bank accounts reflect that change?
- A PSP says customer funds are fully safeguarded while sourcing all payouts in 60 countries from a payout network. Which form could it take? Are the claims contradictory?
- Why do scaled PSPs often own their balance-core permissions while rarely participating directly in clearing in every country? Use the fixed-cost explanation.
8. Answers¶
Try answering before reading on.
StarMap retains €56; €944 now belongs to the PSP. At 10:30 the ledger records €56 available, no reservation and €944 attributable to the PSP's own funds. At 18:00, €944 moves to the PSP's own German account, leaving €50,056 safeguarded. During the interval, the ledger knows the ownership split even though bank-account placement has not caught up. Reconciliation clears the difference.
It could have an owned core with sourced endpoints, or a partner core with sourced endpoints. The identity of the safeguarded-account holder helps distinguish them. There is no contradiction: safeguarding concerns customer balances; sourcing a payout network concerns local delivery. The network pays with its local currency and the PSP settles with it afterward. Funds released for that settlement go to the network's settlement account, rather than directly to the beneficiary.
A balance-core licence supports all relevant customers in a large market, spreading its fixed cost over the whole business there. Direct clearing access adds a separate fixed cost in each country, which must be justified by that country's volume. The cost rule is the same; the volume over which the cost is spread differs.
Previous: Chapter 4 · Payout Endpoints: Turning a Balance into Money Received Next: Chapter 6 · Acquiring: From a Collection Account to Merchant Transactions