Payout Endpoints: Turning a Balance into Money Received
Part I · PSP Architecture (Chapters 1–5) Builds on: Payment Systems, Chapter 10 (speed, irrevocability and prefunding), Chapter 17 (Confirmation of Payee), Chapter 18 (liquidity costs), Chapter 19 (local customer payments and cross-border funding) New concepts in this chapter: liquidity pool, prefunding, beneficiary validation, payout state machine, customer FX and treasury rebalancing
1. The question from the previous chapter¶
StarMap wants to pay £800 to its UK illustrator. Where does the PSP obtain sterling, how much must it hold in advance, and how does it know the payment arrived?
A payout endpoint handles this stage: send money over a country's local rails and report each result to the balance core. It mirrors the pay-in endpoint but adds a requirement: the money must be there before the payout starts.
2. The money must be there first¶
Müller's €1,000 sits in the PSP's German safeguarded account. The illustrator needs pounds in the UK. The German and UK accounts have no automatic connection that turns euros into sterling and moves them to Britain.
The Wise model distinguishes an individual customer payment from the funding behind it: the customer payment stays local, but the provider still moves funds across borders. Without sterling already in the UK, the payout endpoint has nothing to send.
The sterling available for UK payouts forms the PSP's sterling liquidity pool. To fulfill StarMap's instruction, the endpoint draws £800 from that pool and sends it over Faster Payments, or FPS.
The pool can draw on three sources, held separately according to ownership:
| Source | Whose money is it, and where is it held? | When is it replenished? |
|---|---|---|
| Customer balances already converted to sterling | Customer funds in a sterling safeguarded account, under the balance core rules | When customers convert funds |
| Sterling placed in advance by the PSP | The PSP's own funds in its UK account | When the PSP anticipates a shortfall |
| Temporary funding from a payout partner | The partner's funds on its own books | At payment, with settlement afterward |
StarMap converts euros directly into a sterling payout without holding a sterling balance, so this example uses the second source. This is prefunding. It is a central cost of the PSP model: money waiting in the UK account incurs a funding cost every day. This is the prefunded-liquidity cost introduced in the four sources of cross-border cost.
3. Licensing requirements, plus the duty to check the beneficiary¶
Paying for customers in the UK requires permission to provide the service and access to the clearing rail. These are the same two structural requirements as for collections. The same direct-versus-indirect access choices apply.
Outbound payments add a compliance responsibility: the initiating provider must check the recipient. For an incoming payment, the payer's bank has primary responsibility for identifying its payer. For an outgoing payment, the PSP must check the beneficiary, sanctions exposure and suspicious activity. The relevant checks introduced in the compliance skeleton, including OFAC sanctions screening and required sender/recipient information under the Travel Rule, become part of payout processing.
Beyond permission and clearing access, the two directions differ as follows:
| Pay-in endpoint | Payout endpoint | |
|---|---|---|
| Checking the other party | Primarily the payer's bank's responsibility | The PSP's responsibility |
| Funds required in advance | No | Yes |
4. Engineering requirements: validate, reserve, pay and track¶
Follow StarMap's £800 payout.
Step 1: validate the beneficiary
StarMap enters the illustrator's UK account details and name. Before sending, the endpoint checks:
- Whether the account format is valid and the sort code, the UK bank-routing code, exists.
- Whether the account and name match. The UK's Confirmation of Payee (CoP) and the euro area's Verification of Payee (VoP), mandatory there from October 2025, ask the receiving bank to check the name and warn about mismatches.
- Whether the beneficiary appears on sanctions or internal risk lists.
Under the policy in this example, a failed check stops the payment before StarMap's balance changes.
Step 2: reserve the balance
Once the checks pass, the core reduces StarMap's available euros by €944, the quoted cost of £800, and increases its reserved euros by €944. As the balance core explains, a reservation prevents a second spend while the payment remains incomplete.
Step 3: pay from the liquidity pool
The endpoint checks whether the sterling pool contains at least £800. If so, it sends the payment over FPS. Otherwise, the payment waits for replenishment or uses partner funding.
Step 4: track the state and update the ledger
FPS normally returns a result in seconds, but the endpoint must handle every result:
| State | Meaning | Core ledger action |
|---|---|---|
| Accepted | The PSP accepted and validated the instruction | Reduce available funds; increase reserved funds |
| Sent | The instruction has been submitted to the rail | No further balance change |
| Credited | The rail confirms credit to the beneficiary's account | Clear the reservation and complete the deduction |
| Failed | The rail rejected the payment before funds went out, for example because the account does not exist or the receiving bank refused it | Clear the reservation; restore available funds |
| Returned | Funds went out but were returned later, for example because of a closed account or name issue | Credit the returned amount back to available funds |
Success is the normal path. Engineering quality is tested by the last two rows: failures and returns need ledger handling as automatic as success. If each return needs manual work, volume soon produces dozens of manual cases a day.
Timelines vary by rail, so state rules must be rail-specific:
| Rail | Submission to confirmation | Return exposure |
|---|---|---|
| UK FPS, euro instant payments | Seconds | Very limited ordinary return exposure after final credit |
| Standard SEPA transfer | One business day | Account-related returns may arrive within days |
| US ACH | One to two business days | Returns can arrive days later |
| Domestic batch transfers | One to three business days | Depends on local rules; often several days |
In this comparison, faster rails shorten the gap between sending and final confirmation. Slower rails leave a longer interval during which the endpoint must answer the customer's question: "Where is my payment?"
Three-way reconciliation
Every bank debit must have a corresponding payout record. Every confirmed payout must have a matching ledger deduction. Every ledger deduction must trace to a real bank debit. Extra entries, missing entries and inconsistent states must be resolved daily, just as on the pay-in side.
5. Customer FX and treasury rebalancing are separate operations¶
StarMap holds euros but the illustrator receives pounds. Two different operations connect them: customer FX and the PSP's treasury rebalancing.
Customer FX is what StarMap sees. The PSP quotes approximately £0.8475 per euro: paying £800 costs €944 in the rounded example. StarMap accepts. Its euro balance falls by €944, and £800 leaves the sterling pool. The PSP includes a spread in its quote as a source of revenue.
Treasury rebalancing happens behind the scenes. Over a day, the PSP's own German account accumulates euros from customer conversions like StarMap's €944, while its UK account loses sterling through payouts. Its treasury team manages the net position: perhaps €50,000 of net euro inflows and £40,000 of net sterling outflows. It makes an institutional FX trade for the net amount and moves funds between its own German and UK accounts, rather than doing so for each customer payment.
That funding transfer often uses SWIFT. The customer's individual payment stays local; the PSP's funding still crosses borders, in larger net batches at lower frequency. The Wise model describes the tradeoff as replacing slow, expensive individual transfers with capital tied up in liquidity and the need for licences. The pool is where that capital sits.
| Customer FX | PSP treasury rebalancing | |
|---|---|---|
| Initiator | Customer | PSP treasury team |
| Frequency | Per payment | Daily or less frequently |
| Amount | Individual transaction | Net amount |
| Customer visibility | Visible quote and confirmation | Behind the scenes |
| Mechanism | Currency conversion recorded on the ledger | Actual cross-border funding, often over SWIFT |
Customer FX can happen in seconds because it changes internal records. Rebalancing moves real funds across borders and depends on bank hours and cross-border rails. The payout endpoint uses the liquidity pool to bridge that timing gap, which is why prefunding is necessary.
The pool must cover expected net outflows until the next replenishment, plus a safety margin. Too much ties up expensive capital; too little makes payouts queue. Dozens of payout countries mean dozens of pools, helping explain why PSPs often use partners in smaller markets.
6. Build or buy permission, access, liquidity and operations separately¶
| Component | Building it | Using a partner | Common approach |
|---|---|---|---|
| Local payout permission | Hold a licence valid in the market | Use a locally licensed provider | Own permissions in major markets, partners elsewhere |
| Clearing access | Direct participation | Indirect access through a sponsor bank | Direct in high-volume markets |
| Liquidity pool | Prefund, convert currencies and manage positions yourself | Partner supplies local currency at payment, charging through the spread or per-payment fee | Manage major currencies; buy coverage for smaller currencies and peaks |
| Beneficiary validation, states and reconciliation | Run your own systems | Use partner results | Validation can be sourced; reconciliation responsibility remains |
Liquidity is the payout-specific row. A payout network maintains local funds across dozens or hundreds of markets. One integration gives a PSP access to those destinations, at a price that includes the partner's funding costs and profit. A PSP advertising payouts to 120 countries will often operate a few endpoints itself and source the rest.
7. The questions this raises¶
We have now examined the core and both endpoint types separately. What happens at every step as Müller's payment becomes the illustrator's receipt? What does a PSP look like when all the build-or-partner decisions are combined? What does this reveal about Wise, Airwallex and Nium?
The next chapter joins the components into one end-to-end payment.
8. Self-check questions¶
- A payout remains Sent for three days and the illustrator reports no receipt. Where might it be, and what state is StarMap's balance in?
- A sterling pool loses about £40,000 net per business day, is replenished weekly and needs a 30% safety margin. How much should it hold? At a 6% annual funding cost, what is the approximate annual cost?
- Use customer FX and treasury rebalancing to explain why instant customer conversion can coexist with a continuing need for SWIFT.
9. Answers¶
Try answering before reading on.
It may still be awaiting settlement on a slow rail, have reached the receiving bank without customer credit, or be returning from that bank with the return still in transit. StarMap's amount remains reserved: unavailable for another spend, but not yet recorded as a completed payout. The endpoint needs enough tracking to distinguish these situations.
Five business days of net outflows require £40,000 × 5 = £200,000. Adding 30% gives £260,000. Applying 6% to that funded amount gives an illustrative annual cost of £15,600. That is one currency pool; operating in 30 countries can require managing 30 such pools.
Customer FX changes records under the PSP's control, allowing a euro balance to fund a payout from a sterling pool in seconds. That works only because the sterling was already there. Moving the PSP's own funds into the UK is a real cross-border transfer using SWIFT or another funding rail. SWIFT shifts from each customer payment to periodic treasury transfers, so its timing no longer directly determines the customer's experience while the pool remains funded.
Previous: Chapter 3 · Pay-in Endpoints: Identifying Incoming Money Next: Chapter 5 · Putting It Together: A Cross-Border Payment from Start to Finish