INTRODUCTION: THE MISDIRECTED PAYMENT EPIDEMIC

In Lesson 6.1, we built the payment initiation engine. The PSU authorizes a payment to a specific creditor account. However, what if the PSU mistypes the payee’s account number? Or what if a fraudster impersonates a legitimate payee and provides a fake account number? The payment would be executed, the funds would be lost, and the PSU would have no recourse.

The problem is staggering. In the UK alone, misdirected payments (also known as “authorised push payment” or APP fraud) cost consumers over £500 million annually. The victim authorises a payment to a fraudster’s account, believing it to be a legitimate payee. The funds are transferred, and by the time the error is discovered, the money is gone.

Confirmation of Payee (CoP) , also known as the Payee Verification service, is the cryptographic and operational solution to this epidemic. Under PSD2, the Confirmation of Payee Information Provider (CBPII) is a specialised TPP category that provides a service to verify that the payee’s name matches the provided account number. The CBPII does not initiate payments; it only provides the verification result (Match, Partial Match, or No Match) to the PISP or the PSU.

This lesson deconstructs the CBPII architecture. We define the POST /funds-confirmation-consents endpoint (OBIE v4.0), the POST /funds-confirmations resource, and the exact JSON payloads. We mathematically model the fraud reduction using Bayes’ theorem, proving that CoP reduces the probability of a misdirected payment from 1 in 1,000 to 1 in 1,000,000. We also quantify the latency budget for the confirmation request (≤ 200ms), which is significantly faster than a full payment initiation (which requires SCA), as the CBPII is exempt from SCA under RTS Article 18. We will formally define the fuzzy matching algebra using Levenshtein distance, Jaro-Winkler, and Soundex algorithms, deriving the optimal similarity threshold that maximises the F1-score (Precision vs. Recall). We will also analyse the business model for the CBPII service, deriving the break-even point for fraud prevention and the optimal fee structure.

LEARNING OBJECTIVES

1. Define the CBPII Regulatory Framework—citing PSD2 Article 66 (CBPII as a subcategory of PISP), the RTS on SCA (exemption for CBPII under Art. 18), the EBA’s guidelines on the CBPII service, and mapping these to the OBIE v4.0 Funds Confirmation API.

2. Deconstruct the Funds Confirmation Consent—parsing the POST /funds-confirmation-consents endpoint, which creates a one‑time consent for a single funds confirmation request (valid for 10 minutes), and differentiating it from the long‑lived AISP consent and the payment consent.

3. Design the Funds Confirmation Request—implementing the POST /funds-confirmations endpoint, which accepts a DebtorAccount, CreditorAccount, and InstructedAmount, and returns a ConfirmationResult (Match, PartialMatch, NoMatch).

4. Formalize the Fuzzy Matching Algebra—deriving the mathematical formulations for Levenshtein Distance (d(s1, s2)), Jaro-Winkler Similarity (sim_jw(s1, s2)), and Soundex encoding, and deriving the optimal threshold θ that maximises the F1-score using the Youden’s Index (J = Sensitivity + Specificity - 1).

5. Quantify the Fraud Reduction—applying Bayes’ Theorem to model the impact of CoP: defining the prior probability of a fraudster attempting to impersonate a payee (P(F) = 0.001), and calculating the posterior probability after a successful “Match” response (P(F|M) ≈ 1e-7), proving that CoP reduces the fraud success rate by a factor of 10,000x.

6. Calculate the CBPII Latency Budget—decomposing the end‑to‑end latency of a funds confirmation request: consent lookup (2ms), account name retrieval (5ms), fuzzy matching (10ms), and network transmission (50ms), and proving that the total p95 latency is under 200ms, making it suitable for real‑time payment initiation.

7. Analyze the Business Model—deriving the break‑even point for fraud prevention: the expected fraud loss without CoP (E[Loss] = P(F) × L), with CoP (E[Loss]' = P(F|M) × L), and the fee structure (Fee ≤ E[Loss] - E[Loss]'), proving that a fee of £0.05 per confirmation is highly cost‑effective.

8. Design the CBPII Integration with PISP Flow—creating a unified sequence diagram that integrates the CBPII confirmation request into the payment initiation flow, reducing the risk of misdirected payments without adding more than 200ms to the total latency.

PART 1: THE CBPII REGULATORY FRAMEWORK — A Sub‑Category of the PISP

1.1 The Legal Basis

Under PSD2, the CBPII is defined as a Payment Initiation Service Provider that provides a service to confirm the payee. The CBPII does not initiate the payment; it only verifies the payee’s details.

PSD2 Article 66(2) : “Payment initiation service providers may also provide a service to confirm the availability of funds and the consistency of the payee’s account with the provided payment order.”

SCA Exemption (RTS Article 18) : The CBPII is exempt from Strong Customer Authentication (SCA) if:

• The CBPII is not initiating a payment.

• The CBPII is authorised and registered.

• The CBPII does not access the PSU’s account balance (only the payee’s name).

The EBA’s Guidelines on CBPII (EBA/GL/2022/05) :

• The CBPII must obtain explicit consent from the PSU for each confirmation request.

• The consent must be specific to a single payee and a single account.

• The CBPII must not store the payee’s details for longer than necessary.

The OBIE v4.0 Funds Confirmation API:
The CBPII API consists of two critical endpoints:

1. POST /funds-confirmation-consents — Creates a one‑time consent for a confirmation request.

2. POST /funds-confirmations — Executes the confirmation request.

The Regulatory Distinction:

• AISP: Reads data (balances, transactions). Long‑lived consent (90 days).

• PISP: Initiates payments. Short‑lived consent (24 hours, one‑time use).

• CBPII: Confirms payee details. One‑time consent (10 minutes).

1.2 The CBPII License and Capital Requirements

The CBPII does not require a separate license; it is a sub‑category of the PISP license. However, the CBPII must register with the competent authority (e.g., the FCA in the UK) and maintain a minimum capital of €50,000 (as per PSD2 Art. 14).

1.3 The CBPII’s Operational Constraints

The CBPII must:

• Provide a clear disclosure: The CBPII must inform the PSU that only the payee’s name is being verified, not the amount or the purpose.

• Maintain a fraud detection system: The CBPII must monitor the volume of confirmation requests to detect potential abuse.

• Ensure data minimisation: The CBPII must not store the payee’s details after the confirmation request is fulfilled.

PART 2: THE FUNDS CONFIRMATION CONSENT — One‑Time and Short‑Lived

Unlike a payment consent (which can last 24 hours and be used once), a funds confirmation consent is one‑time and short‑lived (valid for 10 minutes). This is because the confirmation is a simple yes/no query, not a multi‑step flow. The 10‑minute TTL ensures that the PSU’s authorisation is fresh and reduces the risk of misuse.

2.1 The OBIE v4.0 Funds Confirmation Consent Schema

POST /funds-confirmation-consents request body:

{
  "Data": {
    "ConsentId": null, // ASPSP generates
    "CreationDateTime": null, // ASPSP generates
    "Status": "AwaitingAuthorisation",
    "DebtorAccount": {
      "SchemeName": "UK.OBIE.SortCodeAccountNumber",
      "Identification": "1234567890"
    },
    "CreditorAccount": {
      "SchemeName": "UK.OBIE.SortCodeAccountNumber",
      "Identification": "0987654321"
    },
    "ExpirationDateTime": "2026-08-03T14:40:00Z" // 10 minutes
  },
  "Risk": {
    "PaymentContextCode": "BillPayment",
    "MerchantCategoryCode": "4900"
  }
}

Mandatory Fields:

• DebtorAccount: The PSU’s account (to ensure the PSU is authorised to request the confirmation).

• CreditorAccount: The payee’s account (to be verified).

Optional Fields:

• ExpirationDateTime: Defaults to 10 minutes after creation.

Response (201 Created) :

{
  "Data": {
    "ConsentId": "fc-abc-123",
    "CreationDateTime": "2026-08-03T14:30:00Z",
    "Status": "AwaitingAuthorisation",
    "ExpirationDateTime": "2026-08-03T14:40:00Z"
  },
  "Links": {
    "self": "/funds-confirmation-consents/fc-abc-123"
  }
}

2.2 The Funds Confirmation Consent State Machine

The state machine for a funds confirmation consent is simpler than the payment consent.

+-----------------------------------------------------------------------+
|         FUNDS CONFIRMATION CONSENT STATE MACHINE (OBIE v4.0)           |
+-----------------------------------------------------------------------+
|                                                                        |
|  POST /funds-confirmation-consents                                    |
|          |                                                            |
|          v                                                            |
|   +------------------+                                                |
|   | AwaitingAuth     | ← Initial state. PSU must authorise.           |
|   +------------------+   (TTL: 10 minutes)                          |
|          |                                                            |
|          | (PSU authorises via consent screen)                        |
|          v                                                            |
|   +------------------+                                                |
|   | Authorised       | ← PSU granted consent. Confirmation can be     |
|   +------------------+   executed. (TTL: until consent expires)      |
|          |                                                            |
|          | (TPP submits confirmation request)                         |
|          v                                                            |
|   +------------------+                                                |
|   | Consumed         | ← Confirmation executed. Consent cannot be     |
|   +------------------+   reused. (Final state)                       |
|                                                                        |
|  Alternative Paths:                                                    |
|  - If PSU rejects → Rejected (Final state)                            |
|  - If TTL expires (10m) → Expired (Final state)                       |
+-----------------------------------------------------------------------+

State Transition Rules:

• AwaitingAuthorisation → Authorised: When the PSU explicitly authorises the confirmation request (no SCA required, but consent must be explicit).

• Authorised → Consumed: When the TPP submits the confirmation request.

• AwaitingAuthorisation → Expired: If 10 minutes elapse without authorisation.

Idempotency on Consent Creation:
The POST /funds-confirmation-consents endpoint also supports the x-idempotency-key header. If the TPP retries the request, the ASPSP returns the same ConsentId and status. This prevents duplicate consent creation.

2.3 The PSU Interaction (No SCA)

The PSU does not perform SCA for the funds confirmation consent, because the CBPII is exempt from SCA under RTS Article 18. However, the PSU must still be redirected to the ASPSP’s consent page to explicitly authorise the confirmation request. This page displays the payee’s account details and asks: “Do you want to confirm this payee?” The PSU clicks “Yes” (no OTP required), and the consent transitions to Authorised.

The SCA Exemption Justification: The EBA’s rationale is that a confirmation request does not move funds; it only reveals a name. The risk of fraud is minimal compared to payment initiation. However, the PSU must still be informed that the confirmation is being performed.

PART 3: THE CONFIRMATION REQUEST — Checking the Name and Account

Once the consent is Authorised, the TPP submits the POST /funds-confirmations endpoint.

3.1 The Confirmation Request Payload

POST /funds-confirmations request body:

{
  "Data": {
    "ConsentId": "fc-abc-123",
    "ConfirmationId": null, // ASPSP generates
    "CreditorAccount": {
      "SchemeName": "UK.OBIE.SortCodeAccountNumber",
      "Identification": "0987654321"
    },
    "CreditorName": "Acme Corporation",
    "InstructedAmount": {
      "Amount": "100.00",
      "Currency": "GBP"
    }
  }
}

Mandatory Fields:

• ConsentId: The ID of the authorised consent.

• CreditorAccount: The payee’s account (must match the consent).

• CreditorName: The name the PSU expects the payee to have.

Optional Fields:

• InstructedAmount: The amount (optional, but recommended for fraud detection).

Response (200 OK) :

{
  "Data": {
    "ConfirmationId": "cf-123",
    "ConsentId": "fc-abc-123",
    "CreationDateTime": "2026-08-03T14:31:00Z",
    "ConfirmationResult": "Match", // Or "PartialMatch", "NoMatch"
    "ConfirmationName": "Acme Corporation" // The matched name (if available)
  },
  "Links": {
    "self": "/funds-confirmations/cf-123"
  }
}

The Three Confirmation Results:

3.2 The ASPSP’s Internal Logic (The Matching Engine)

The ASPSP receives the confirmation request and performs the following steps:

1. Account Lookup: Query the database for CreditorAccount (sort code + account number).

2. Retrieve Registered Name: Fetch the registered account holder’s name (e.g., “Acme Corporation”).

3. Name Comparison: Compare the provided CreditorName with the registered name using fuzzy matching algorithms (Levenshtein distance, Jaro-Winkler, Soundex).

4. Score Aggregation: Combine the scores from multiple algorithms using a weighted sum.

5. Threshold Decision: If the aggregated score ≥ θ, return Match. If θ_low ≤ score < θ, return PartialMatch. If score < θ_low, return NoMatch.

Latency:

• Account Lookup: 5ms (p95).

• Name Comparison: 10ms (p95) for a single pair.

• Total ASPSP processing: 15ms.

PART 4: THE FUZZY MATCHING ALGEBRA — A Mathematical Formulation

The name comparison is the core of the CBPII service. We formalise the three algorithms and derive the optimal threshold.

4.1 Levenshtein Distance (Edit Distance)

The Levenshtein distance d(s1, s2) is the minimum number of single-character edits (insertions, deletions, or substitutions) required to transform s1 into s2.

Mathematical Definition:
d(s1, s2) = min( d(s1[1:], s2) + 1, d(s1, s2[1:]) + 1, d(s1[1:], s2[1:]) + (s1[0] != s2[0]) )

Normalized Similarity:
Sim_Lev = 1 - d(s1, s2) / max(|s1|, |s2|)

Example:

• s1 = "Acme Corp", s2 = "Acme Corporation".

• d = 4 (insert or, a, t, i).

• max(|s1|, |s2|) = 18.

• Sim_Lev = 1 - 4/18 = 0.777.

Complexity: O(|s1| × |s2|). For typical merchant names (≤ 50 characters), this is trivial.

4.2 Jaro-Winkler Similarity

The Jaro-Winkler distance is designed for short strings (e.g., personal names). It gives higher weight to prefix matches.

Jaro Similarity:
Sim_j = (1/3) × (m/|s1| + m/|s2| + (m - t)/m)
Where:

• m is the number of matching characters (within a window of floor(max(|s1|, |s2|)/2) - 1).

• t is the number of transpositions.

Winkler Adjustment:
Sim_jw = Sim_j + 0.1 × l × (1 - Sim_j)
Where l is the number of matching prefix characters (max 4).

Example:

• s1 = "Acme Corp", s2 = "Acme Corporation".

• Prefix: l = 4 (“Acme”).

• Sim_j = 0.85, Sim_jw = 0.85 + 0.1 × 4 × (0.15) = 0.91.

Threshold: For Jaro-Winkler, a threshold of 0.92 is commonly used for Match.

4.3 Soundex Encoding

Soundex is a phonetic algorithm that encodes names based on their pronunciation. It is useful for matching names that sound similar (e.g., “Smith” vs “Smyth”).

Soundex Algorithm:

1. Keep the first letter.

2. Convert consonants to digits (B, F, P, V → 1; C, G, J, K, Q, S, X, Z → 2; etc.).

3. Remove vowels (A, E, I, O, U, H, W, Y).

4. Keep the first 4 characters (letter + 3 digits).

Example:

• "Acme" → A250.

• "Akme" → A250 (Soundex match).

Soundex is a boolean match: If Soundex(s1) == Soundex(s2), return True; else False.

4.4 Aggregated Score and Threshold Optimization (Youden’s Index)

We combine the three algorithms into a weighted score:

Total_Score = w1 × Sim_Lev + w2 × Sim_Jw + w3 × Soundex_Boolean

Typical weights: w1 = 0.4, w2 = 0.4, w3 = 0.2.

Optimal Threshold (Youden’s Index) :
We want to maximise the F1-score (Precision vs. Recall). We use Youden’s Index on a labelled test set (10,000 known matches and non-matches):

J = Sensitivity(θ) + Specificity(θ) - 1

The optimal threshold θ maximises J.

Empirical Results (based on industry data):

Optimal Threshold: θ = 0.94. This gives 99.9% Precision (almost zero false positives) and 95% Recall (95% of legitimate matches are correctly identified). The 5% false negatives (legitimate payments flagged as “NoMatch”) are acceptable, as the PSU can manually verify the payee.

PART 5: THE FRAUD REDUCTION MATHEMATICS — Bayes’ Theorem

We model the impact of Confirmation of Payee on fraud reduction.

Definitions:

• F: Event of a fraudulent payment attempt (the PSU is tricked into sending money to a fraudster’s account).

• M: Event of a Confirmation of Payee returning “Match”.

• P(F): Prior probability that a payment is fraudulent. Industry estimate: 0.1% (1 in 1,000) .

• P(M | F): Probability that a fraudulent payment still returns “Match” because the fraudster uses an account with a name that matches the legitimate payee’s name (e.g., the fraudster opens a bank account with a similar name to the legitimate payee). Estimated: 0.01% (1 in 10,000) , based on the number of successful APP fraud cases where the name matched.

• P(M | ¬F): Probability that a legitimate payment returns “Match”. Estimated: 99.9% (0.999) .

Posterior Probability (Fraud given a “Match”) :
Using Bayes’ Theorem:

P(F | M) = P(M | F) × P(F) / [ P(M | F) × P(F) + P(M | ¬F) × P(¬F) ]

Plugging in numbers:

• P(M | F) = 0.0001

• P(F) = 0.001

• P(M | ¬F) = 0.999

• P(¬F) = 0.999

P(F | M) = (0.0001 × 0.001) / (0.0001 × 0.001 + 0.999 × 0.999)
= (1e-7) / (1e-7 + 0.998001)
= 1e-7 / 0.998001
≈ 1.002 × 10^-7

Conclusion: After a successful “Match” confirmation, the probability that the payment is fraudulent drops from 0.1% to 0.00001% (1 in 10 million) . This is a 10,000x reduction.

The Fraud Reduction Factor:
Reduction = P(F) / P(F|M) = 0.001 / 1e-7 = 10,000.

Business Impact:

• Total APP fraud losses in the UK: £500 million per year.

• With CoP, the expected losses are reduced to £500 million / 10,000 = £50,000.

• Annual saving: £499.95 million.

PART 6: THE CBPII LATENCY BUDGET — Meeting the Real-Time Requirement

The CBPII confirmation must be fast enough to be integrated into the payment initiation flow without adding unacceptable latency.

6.1 Latency Decomposition

Conclusion: The p95 latency is 120ms, which is well under the 200ms target. The confirmation request is almost instantaneous from the PSU’s perspective.

6.2 The Impact on Payment Latency

The CBPII confirmation adds 120ms to the overall payment flow. The total payment latency (from Lesson 6.1) is 4.22s (Pix) to 6.12s (SEPA). Adding 120ms is a 2.8% increase for SEPA and a 2% increase for Pix. This is negligible.

The Payment Flow with CBPII:

1. CBPII Confirmation (120ms) → 2. Payment Consent + SCA (4s) → 3. Payment Submission (20ms) → 4. Clearing (0.5s) → 5. Settlement (50ms).

• Total Pix: 120ms + 4s + 20ms + 100ms + 50ms = 4.29s (vs 4.22s without).

• Total SEPA: 120ms + 4s + 20ms + 2000ms + 50ms = 6.19s (vs 6.12s without).

PART 7: CBPII INTEGRATION WITH PISP FLOW — A Unified Sequence Diagram

The CBPII confirmation is integrated into the payment initiation flow to ensure that the PSU verifies the payee before authorising the payment.

+-----------------------------------------------------------------------+
|         CBPII + PISP UNIFIED FLOW — VERIFY BEFORE PAY                 |
+-----------------------------------------------------------------------+
|                                                                        |
|  TPP (PISP/CBPII)      ASPSP (Bank)           PSU (User)              |
|     |                      |                     |                     |
|     |--(1) POST /funds-confirmation-consents-->|                     |
|     |  (Debtor: 123... Creditor: 098...)       |                     |
|     |                      |                     |                     |
|     |<-(2) 201 Created------|                     |                     |
|     |  ConsentId: fc-123   |                     |                     |
|     |                      |                     |                     |
|     |--(3) Redirect PSU---->|                     |                     |
|     |  (Consent page)      |                     |                     |
|     |                      |                     |                     |
|     |                      |<-(4) Display------|                     |
|     |                      |  "Confirm payee:  |                     |
|     |                      |   Acme Corp?"     |                     |
|     |                      |                     |                     |
|     |                      |<-(5) PSU approves--|                     |
|     |                      |  (No SCA)         |                     |
|     |                      |                     |                     |
|     |<-(6) Redirect--------|                     |                     |
|     |  (Consent Authorised)|                     |                     |
|     |                      |                     |                     |
|     |--(7) POST /funds-confirmations----------->|                     |
|     |  (ConsentId: fc-123,                       |                     |
|     |   CreditorName: Acme Corp)                |                     |
|     |                      |                     |                     |
|     |                      |--(8) Fuzzy Match-->|                     |
|     |                      |  (Levenshtein,     |                     |
|     |                      |   Jaro-Winkler)    |                     |
|     |                      |                     |                     |
|     |<-(9) 200 OK----------|                     |                     |
|     |  Result: Match      |                     |                     |
|     |                      |                     |                     |
|     |--(10) POST /domestic-payment-consents---->|                     |
|     |  (Amount: £100, Payee: Acme Corp)        |                     |
|     |                      |                     |                     |
|     |<-(11) 201 Created-----|                     |                     |
|     |  ConsentId: pc-123   |                     |                     |
|     |                      |                     |                     |
|     |--(12) Redirect PSU--->|                     |                     |
|     |  (SCA Challenge)    |                     |                     |
|     |                      |                     |                     |
|     |                      |<-(13) SCA--------|                     |