Pay-in Endpoints: Identifying Incoming Money
Part I · PSP Architecture (Chapters 1–5) Builds on: Payment Systems, Chapter 9 (push, pull and return windows), Chapter 15 (direct clearing access), Chapter 17 (three levels of FPS access), Chapter 25 (reconciliation) New concepts in this chapter: virtual account, direct and indirect participation, receipt and availability, three-way reconciliation
1. The question from the previous chapter¶
On the day Müller paid, 137 receipts arrived in the PSP's German bank account. How did the PSP identify StarMap's payment? Could it immediately make the money available?
Both questions arise before money enters the balance core. A pay-in endpoint handles this stage: collect locally, identify the customer entitled to the funds, and tell the core when that customer may use them.
We start with identification, then examine licensing and engineering requirements.
2. One account, hundreds of customers: identifying the owner¶
The simplest arrangement is one bank account, with payers instructed to include a customer ID in the payment reference. Problems soon appear:
- Müller's accountant forgets the reference.
- She types STAR-0024 instead of STAR-0042.
- She enters it correctly, but her bank truncates the reference to 35 characters, cutting off part of the ID.
Each mistake creates a receipt whose owner is unknown. These are a major source of the unidentified-receipts balance described in the previous chapter.
A better approach is a distinct account number for each customer. The destination account identifies the customer without an extra reference. But opening a real bank account for every customer means hundreds of separate account-opening reviews.
The industry solution is a set of sub-account numbers beneath the PSP's master account. Each has its own IBAN. The payer sees an ordinary German account number and makes an ordinary SEPA transfer. The bank tells the PSP which sub-account number received the payment, while the funds themselves land in the master account. The sub-account number does not hold a separate pot of money. We call it a virtual account, often a virtual IBAN in Europe and a virtual account in the US and Asia.
| Identification method | What the payer must do | Misidentification risk | Cost to the PSP |
|---|---|---|---|
| Customer ID in the reference | Remember it and enter it correctly | High | Almost none |
| Virtual account | Send to the supplied IBAN; no extra reference step | Very low | Bank fees per account number or per month |
| A real account per customer | No extra identification step | Very low | Separate onboarding for every account, limiting scale |
The underlying variable is who supplies the identifying information. A manually entered reference can be omitted or mistyped. A system-assigned account number embeds that information in the destination itself, removing the separate reference-entry failure.
StarMap's DE IBAN is a virtual account number supplied by the PSP's German partner bank.
3. Licensing requirements: local collection permission and clearing access¶
A pay-in endpoint must clear two hurdles, each answering a different question.
First: who permits you to collect for customers in Germany? Collecting on someone else's behalf is a payment service. The PSP needs suitable EU permissions extended to Germany through passporting, or a licensed local provider performing the service. This is the same regulatory framework used for the balance core, but the question is permission to collect locally. An appropriately authorized EU EMI can hold balances and collect in Germany. A Singapore licence alone does not provide German collection permission; the PSP needs a locally authorized partner.
Second: how do you access the clearing rail? Müller's SEPA transfer must ultimately reach an account belonging to a clearing-system participant. The question of who can enter directly, raised in euro-area clearing rails, now becomes practical. A PSP can become a direct participant, or access the system through a participating bank as an indirect participant.
| Access model | Who appears in the clearing system? | Who supplies collection details? | Entry requirements |
|---|---|---|---|
| Direct | The PSP, with a settlement account at the central bank or clearing institution | The PSP issues IBANs under its own bank code | Nonbank access must be permitted; the PSP must meet capital, technical and operational requirements |
| Indirect | A bank acting for the PSP | The bank supplies IBANs bearing its bank code | Find a willing bank and enter an agreement |
Access for nonbanks differs by jurisdiction:
| Jurisdiction | Can a nonbank PSP directly access domestic retail rails? | Explanation |
|---|---|---|
| UK | Yes, since 2018 | FPS has three access tiers; Wise was the first nonbank direct participant |
| Euro area | Yes, from 2025 | The Instant Payments Regulation amended the Settlement Finality Directive, allowing PIs and EMIs to apply for direct access to designated payment systems |
| Singapore | Yes, since 2021 | Eligible MPI licensees can apply for direct FAST and PayNow access |
| US | Generally no | Direct ACH and FedNow participation requires a Federal Reserve account; nonbank PSPs generally access through banks |
| India and China | No under the retail-clearing model described here | Banks are the direct participants; China's nonbank payment institutions use NetsUnion, a separate clearing arrangement |
The structural question is whether nonbanks can hold the settlement accounts needed at the central bank or clearing institution. Where that route is available, a PSP can obtain its own identifiers and see clearing status directly. Where it is unavailable, the PSP depends on a bank.
That bank is often called a sponsor bank. It receives funds, supplies virtual accounts and passes clearing information to the PSP. Most PSPs participate indirectly in most markets; direct participation usually makes economic sense only in their largest markets.
4. Engineering requirements: receipt, identification, availability and returns¶
Once permission and access are in place, incoming money must be handled correctly. Follow Müller's €1,000 through four steps.
Receipt
On Monday afternoon, Müller initiates a SEPA transfer to StarMap's virtual IBAN. On Tuesday morning, €1,000 reaches the PSP's German master account — the safeguarded account introduced in the previous chapter. The bank also reports the destination virtual account, DE…0042.
Identification
The endpoint looks up DE…0042 and finds StarMap. A virtual account makes this automatic. Without one, staff may have to examine the payment reference manually.
Availability
Can the PSP immediately add €1,000 to StarMap's available balance?
That depends on when the payment can no longer be taken back through the rail's ordinary mechanisms — its finality and return rules. Push and pull explains return windows for pull payments, while push rails around the world explains differences in finality. The endpoint needs a policy for each rail:
| Incoming rail | Can funds still be taken back after receipt? | Endpoint policy in this model |
|---|---|---|
| SEPA credit transfer, UK FPS, instant payments | After interbank settlement, the payer's bank cannot unilaterally take the funds back; it can request a recall | Make funds available on receipt |
| US ACH credit, a push transfer | The originating bank can initiate a return or reversal under applicable rules within limited windows | Decide whether to delay availability based on customer risk |
| Direct-debit or card top-up | The payer may dispute or reverse the payment over weeks or months | Record pending funds, then release them under the applicable risk policy |
Availability reflects the rail's finality rules and the PSP's willingness to take the risk of early release. Earlier finality supports earlier availability. With a longer exposure window, the PSP must either make the customer wait or bear the risk itself.
Müller used a SEPA credit transfer, so the funds become available on Tuesday morning. StarMap sees €1,000 in the app.
Returns
On Wednesday, Müller's accountant realizes she paid the wrong company and asks the bank to recall the transfer. A SEPA recall is a request, not an instruction that automatically retrieves the money. The PSP can refuse, but will commonly cooperate if the payment was genuinely mistaken. A return then reduces StarMap's balance by €1,000.
StarMap may already have spent the funds. Its Tuesday payout of £800 cost €944, leaving €56. Returning €1,000 produces a balance of −€944: an amount StarMap owes the PSP. The endpoint's policy must specify when to return funds and what happens if the customer's balance is insufficient.
Three-way reconciliation
The process creates three records: the bank statement, the endpoint's receipt record and the core ledger. They must agree:
- Every bank receipt has a corresponding endpoint record.
- Every identified endpoint receipt has the corresponding ledger posting.
- Every ledger credit can be traced back to a real bank receipt.
An extra or missing entry is one of the discrepancy types introduced in the previous chapter. Perform three-way reconciliation daily and resolve every difference.
5. Build or buy each part separately¶
A pay-in endpoint combines four things: collection permission, clearing access, bank and virtual-account arrangements, and identification with reconciliation. Each has its own build-or-partner decision:
| Component | Building it | Using a partner | Common approach |
|---|---|---|---|
| Local collection permission | Hold a licence valid in the market | Use a locally licensed institution | Own licences in major markets, partners in smaller markets |
| Clearing access | Participate directly | Participate indirectly through a sponsor bank | Direct in the two or three largest markets, indirect elsewhere |
| Collection and virtual accounts | Issue collection identifiers where direct access permits | Obtain them from a sponsor bank or specialist | Usually sourced from partners; the underlying bank account remains at a bank |
| Identification and reconciliation | Run your own system | Use the partner's identification results | Identification can be sourced; reconciliation responsibility remains |
The final row repeats the balance-core lesson: you can source accounts and identification, but you retain responsibility for reconciliation. Even if the sponsor bank identifies every receipt, StarMap turns to the PSP when its balance is wrong.
Moving from indirect to direct access is worthwhile when transaction volume can absorb the fixed cost and the PSP needs direct clearing visibility rather than waiting for bank updates. Both conditions matter.
6. The questions this raises¶
The funds have arrived and become available. StarMap now wants to pay £800 to its UK illustrator.
The PSP needs sterling in the UK first. Where does it come from, and how much should be prefunded? How will the PSP know the illustrator received it? What ledger changes follow a failed or returned payment?
The next chapter examines payout endpoints, starting with the money in the UK account.
7. Self-check questions¶
- A PSP must access US rails through a bank but can participate directly in the UK. Explain the structural difference without saying merely that US regulation is stricter.
- A customer transfers $5,000 to a PSP over US ACH. Should it become available immediately or later? Explain your criteria.
- Müller requests a recall after StarMap has spent most of its balance. As the PSP's product manager, what must you specify in the pay-in policy?
8. Answers¶
Try answering before reading on.
The relevant difference is access to settlement accounts. Since 2018, eligible nonbank payment institutions have been able to hold settlement accounts at the Bank of England and participate directly in FPS. Direct US ACH and FedNow access requires a Federal Reserve account, generally unavailable to nonbank PSPs. The distinction concerns account eligibility, rather than a general ranking of regulatory strictness.
Examine the ACH credit return rules and the customer's risk profile. Receipt does not eliminate the applicable return or reversal exposure. A cautious policy records pending funds until the main exposure window passes. A PSP may release funds earlier for a trusted customer with a long history, but then takes the risk itself. The two criteria are the rail's rules and the PSP's willingness to bear that customer's risk.
At least four points: (a) when to accept or reject a recall; (b) whether to freeze or deduct the customer's balance when accepting it; (c) how to treat a negative balance, the replenishment deadline and overdue amounts; and (d) which ledger account records the receivable and how reconciliation distinguishes it from actual safeguarded cash. Without these rules, a return leaves the records ambiguous.
Previous: Chapter 2 · The Balance Core: Who Owes the Customer, and How Is Ownership Proven? Next: Chapter 4 · Payout Endpoints: Turning a Balance into Money Received