INTRODUCTION: THE ENGINE OF OPEN BANKING

In Module 5, we mastered the read side of open banking—account aggregation, transaction deduplication, and enrichment. We learned how to pull financial data from multiple banks and present it as a unified, enriched view to the PSU. However, the true power of open banking lies not in reading data, but in acting upon it. Payment Initiation is the “killer app” of open banking.

The Payment Initiation Service Provider (PISP) , defined under PSD2 Article 66, is authorized to initiate payment transactions from a PSU’s account, subject to explicit and informed consent. Unlike traditional online banking, the PISP does not hold the PSU’s credentials; it never touches the funds. Instead, the PISP acts as a secure conduit, transmitting the payment instruction from the PSU to the ASPSP, which executes the transaction.

This lesson deconstructs the complete PISP flow. We begin with the Payment Consent (POST /domestic-payment-consents), where the PISP requests permission to initiate a specific payment (amount, payee, reference). The PSU authenticates (SCA with dynamic linking) and grants consent. The PISP then submits the payment (POST /payments) using a unique idempotency key, which triggers the clearing and settlement process.

We will formalize the payment consent state machine (AwaitingAuthorisation → Authorised → Consumed → Expired), derive the latency budget for each step (consent creation ~50ms, SCA ~3-5s human, clearing varies from 0.1s for Pix to 2s for SEPA), and quantify the idempotency guarantees for payment submission to prevent double debiting. We will also model the clearing and settlement latency using the M/M/1 queuing model for the national clearing house.

LEARNING OBJECTIVES

1. Define the PISP Regulatory Framework—citing PSD2 Article 66 (PISP), Article 67 (Non-discrimination), and the RTS on SCA Article 5 (Dynamic linking), and mapping these to the OBIE v4.0 Payment Initiation API endpoints.

2. Deconstruct the Payment Consent Resource—parsing the exact OBIE v4.0 OBPaymentConsentResponse JSON schema, including the DebtorAccount, InstructedAmount, CreditorAccount, RemittanceInformation, and the Status field (AwaitingAuthorisation, Authorised, Consumed, Rejected).

3. Formalize the Dynamic Linking SCA Challenge—deriving the exact HMAC-SHA256 construction that binds the payment details (amount, payee, reference) to the SCA challenge, and proving mathematically that the probability of a man-in-the-middle attack modifying the payment details is 1 / 2^128.

4. Design the Payment Submission Endpoint—implementing the POST /payments endpoint with the x-idempotency-key header, storing the payment record in a database with a unique constraint on the idempotency key, and returning a 201 Created with the PaymentId and Status (AcceptedSettlementInProcess).

5. Model the Clearing Latency—applying the M/M/1 queueing theory (Kendall notation) to the national clearing house’s processing pipeline, deriving the average waiting time W_q = (λ / μ) / (μ - λ), and calculating the p95 clearing latency for SEPA (2s), Faster Payments (0.5s), and Pix (0.1s).

6. Calculate the End-to-End Payment Latency—summing the consent creation (50ms), SCA human delay (3-5s), payment submission (20ms), clearing (variable), and settlement notification (50ms), and proving that the total latency ranges from 3.2s (Pix) to 7.1s (SEPA) , meeting the PSD2’s “immediate execution” requirement.

PART 1: THE PISP REGULATORY FRAMEWORK — PSD2 Article 66 in Practice

The PISP is a specialized TPP category under PSD2. Its regulatory obligations are distinct from the AISP.

1.1 The Legal Basis

PSD2 Article 66 (Payment Initiation Service Providers) :

• The PISP must provide a service to initiate a payment order at the request of the PSU, without holding the PSU’s funds.

• The PISP must not store the PSU’s sensitive payment credentials (e.g., online banking password).

• The PISP must apply SCA when initiating the payment (unless an exemption applies).

• The PISP must provide a unique reference for each payment (the EndToEndId).

The Non-Discrimination Clause (Art. 67(3)(b)) :
The ASPSP must not discriminate against the PISP. This means the PISP must receive the same SCA experience, the same latency, and the same success rate as the bank’s own payment channel.

The OBIE v4.0 Payment Initiation API:
The OBIE standard defines two critical endpoints for the PISP:

1. POST /domestic-payment-consents — Creates a consent for the payment.

2. POST /payments — Submits the payment using the authorised consent.

1.2 The PISP License and Capital Requirements

To operate as a PISP, the TPP must hold a license from a competent authority (e.g., the FCA in the UK) and maintain adequate capital (€50,000 minimum per PSD2 Art. 14). This ensures the PISP has financial skin in the game if a payment fails due to negligence.

1.3 The PISP’s Operational Constraints

The PISP must:

• Maintain a fraud detection system: The PISP must monitor payment patterns and flag suspicious activity.

• Provide a transparent fee structure: The PISP must inform the PSU of any fees before the payment is initiated.

• Ensure data protection: The PISP must not store the PSU’s account credentials or transaction history (except for audit purposes).

PART 2: THE PAYMENT CONSENT RESOURCE — The Legal Contract for Payment

The payment consent is a separate resource from the payment itself. The consent is created first, authorised by the PSU, and then used to submit the payment.

2.1 The OBIE v4.0 Domestic Payment Consent Schema

POST /domestic-payment-consents request body:

{
  "Data": {
    "ConsentId": null, // ASPSP generates
    "CreationDateTime": null, // ASPSP generates
    "Status": "AwaitingAuthorisation",
    "DebtorAccount": {
      "SchemeName": "UK.OBIE.SortCodeAccountNumber",
      "Identification": "1234567890"
    },
    "InstructedAmount": {
      "Amount": "100.00",
      "Currency": "GBP"
    },
    "CreditorAccount": {
      "SchemeName": "UK.OBIE.SortCodeAccountNumber",
      "Identification": "0987654321"
    },
    "CreditorPostalAddress": {
      "AddressLine": ["1 Main Street", "London"],
      "Country": "GB"
    },
    "RemittanceInformation": {
      "Reference": "INV-001",
      "Unstructured": "Payment for invoice #001"
    },
    "ExpirationDateTime": "2026-08-05T14:30:00Z" // 24 hours max
  },
  "Risk": {
    "PaymentContextCode": "BillPayment",
    "MerchantCategoryCode": "4900",
    "MerchantCustomerIdentification": "cust-123"
  }
}

Mandatory Fields:

• DebtorAccount: The PSU’s account (identified by sort code + account number or IBAN).

• InstructedAmount: The exact amount and currency.

• CreditorAccount: The payee’s account.

• RemittanceInformation: The reference for the payee.

Risk Data:
The Risk object contains fraud-related metadata. The ASPSP uses this to evaluate the risk score (as discussed in Module 3, Lesson 3.7).

Response (201 Created) :

{
  "Data": {
    "ConsentId": "pc-abc-123",
    "CreationDateTime": "2026-08-03T14:30:00Z",
    "Status": "AwaitingAuthorisation",
    "ExpirationDateTime": "2026-08-04T14:30:00Z"
  },
  "Links": {
    "self": "/domestic-payment-consents/pc-abc-123"
  }
}

2.2 The Payment Consent State Machine

A payment consent has a finite lifespan and a strict state transition logic.

+-----------------------------------------------------------------------+
|                PAYMENT CONSENT STATE MACHINE (OBIE v4.0)               |
+-----------------------------------------------------------------------+
|                                                                        |
|  POST /domestic-payment-consents                                      |
|          |                                                            |
|          v                                                            |
|   +------------------+                                                |
|   | AwaitingAuth     | ← Initial state. PSU must authenticate.        |
|   +------------------+   (TTL: 24 hours)                             |
|          |                                                            |
|          | (PSU authenticates via SCA with dynamic linking)           |
|          v                                                            |
|   +------------------+                                                |
|   | Authorised       | ← PSU granted consent. Payment can be          |
|   +------------------+   submitted. (TTL: until consent expires)     |
|          |                                                            |
|          | (TPP submits payment via POST /payments)                   |
|          v                                                            |
|   +------------------+                                                |
|   | Consumed         | ← Payment submitted. Consent cannot be         |
|   +------------------+   reused. (Final state)                       |
|                                                                        |
|  Alternative Paths:                                                    |
|  - If PSU rejects SCA → Rejected (Final state)                        |
|  - If TTL expires (24h) → Expired (Final state)                       |
+-----------------------------------------------------------------------+

State Transition Rules:

• AwaitingAuthorisation → Authorised: Only when the PSU successfully completes SCA.

• AwaitingAuthorisation → Rejected: If the PSU cancels or the SCA fails.

• Authorised → Consumed: When the TPP submits the payment.

• AwaitingAuthorisation → Expired: If 24 hours elapse without authorisation.

• Authorised → Expired: If 24 hours elapse without payment submission.

Idempotency on Consent Creation:
The POST /domestic-payment-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.

PART 3: DYNAMIC LINKING SCA — The Cryptographic Binding

Under RTS Article 5, the SCA challenge must be dynamically linked to the specific payment amount and payee. This prevents a “man-in-the-browser” attack where the PSU authorizes a payment of £10, but the attacker modifies the amount to £1000 after the SCA.

3.1 The HMAC Construction

The ASPSP generates a challenge by computing:

Challenge = HMAC-SHA256( K_Device, Amount || Currency || Payee_ID || Reference || Nonce )

Where:

• K_Device is the PSU’s device-specific secret (stored in the PSU’s hardware token or mobile app secure enclave).

• Amount, Currency, Payee_ID, Reference are the exact values from the payment consent.

• Nonce is a fresh 128‑bit random value generated by the ASPSP.

The PSU’s Device:
The PSU’s hardware token or mobile app computes this HMAC and returns it as the OTP. The ASPSP verifies the OTP by recomputing the HMAC on its side (it stores a synchronized secret or the K_Device in its HSM).

Proof of Binding:
If an attacker intercepts the consent request and changes Amount from £100 to £1000, the HMAC computed by the PSU’s device will be HMAC(1000, ...) which is completely different from the ASPSP’s expected HMAC(100, ...). The OTP fails, and the payment is rejected.

Probability of Tampering:
The probability that an attacker can modify the payment details and predict the correct HMAC is 1/2^256 (for SHA‑256), essentially zero.

3.2 The SCA Flow (Integration with OAuth 2.0)

The SCA challenge is integrated into the OAuth 2.0 authorisation flow. When the PSU is redirected to the ASPSP’s authorisation page, the payment consent details are already present. The ASPSP displays the consent details (amount, payee) and prompts for SCA. The PSU’s device generates the OTP (the HMAC of the consent details). The ASPSP verifies the HMAC and, if successful, issues the authorisation code (JARM) and transitions the consent to Authorised.

Sequence Diagram:

+-----------------------------------------------------------------------+
|            PAYMENT CONSENT WITH SCA DYNAMIC LINKING                    |
+-----------------------------------------------------------------------+
|                                                                        |
|  TPP (PISP)           ASPSP (Bank)            PSU Device               |
|     |                     |                     |                      |
|     |--(1) POST /domestic-payment-consents---->|                      |
|     |  (Amount: £100, Payee: Acme)             |                      |
|     |                     |                     |                      |
|     |<-(2) 201 Created----|                     |                      |
|     |  ConsentId: pc-123  |                     |                      |
|     |  Status: Awaiting   |                     |                      |
|     |                     |                     |                      |
|     |--(3) Redirect PSU--->|                     |                      |
|     |  (Authorisation page)|                     |                      |
|     |                     |                     |                      |
|     |                     |<-(4) Display payment-|                      |
|     |                     |  details to PSU     |                      |
|     |                     |  (£100 to Acme)     |                      |
|     |                     |                     |                      |
|     |                     |--(5) Generate------>|                      |
|     |                     |  challenge:         |                      |
|     |                     |  Nonce = random(16) |                      |
|     |                     |  Challenge = HMAC(  |                      |
|     |                     |    £100 || Acme ||  |                      |
|     |                     |    Nonce, K_Device) |                      |
|     |                     |                     |                      |
|     |                     |<-(6) OTP Response---|                      |
|     |                     |  (from hardware     |                      |
|     |                     |   token/device)     |                      |
|     |                     |                     |                      |
|     |                     |--(7) Verify OTP---->|                      |
|     |                     |  (recompute HMAC,   |                      |
|     |                     |   compare)          |                      |
|     |                     |                     |                      |
|     |                     |--(8) Consent------->|                      |
|     |                     |  Authorised         |                      |
|     |                     |                     |                      |
|     |<-(9) JARM Response--|                     |                      |
|     |  (auth code)       |                     |                      |
|     |                     |                     |                      |
+-----------------------------------------------------------------------+

Latency:

• Step 1-2: 50ms (consent creation).

• Step 3-9: 3-5s (human interaction + cryptographic operations).

• Total: ~3.1-5.1s.

PART 4: THE PAYMENT SUBMISSION ENDPOINT — Executing the Payment

Once the consent is Authorised, the TPP submits the payment using POST /payments.

4.1 The Payment Submission Payload

POST /payments request body:

{
  "Data": {
    "ConsentId": "pc-abc-123",
    "PaymentId": null, // ASPSP generates
    "CreationDateTime": null, // ASPSP generates
    "Status": "AcceptedSettlementInProcess",
    "InstructionId": "pay-001" // TPP's reference
  }
}

Headers:

x-idempotency-key: pay-001-unique
x-fapi-interaction-id: 550e8400-e29b-41d4-a716-446655440000
x-fapi-financial-id: OBIE-UK-123456

The ASPSP’s Response:

201 Created
Location: /payments/pay-456
Content-Type: application/json

{
  "Data": {
    "PaymentId": "pay-456",
    "ConsentId": "pc-abc-123",
    "Status": "AcceptedSettlementInProcess",
    "CreationDateTime": "2026-08-03T14:30:00Z"
  },
  "Links": {
    "self": "/payments/pay-456"
  }
}

4.2 Idempotency Guarantee

The x-idempotency-key is stored in a database table with a unique constraint. If the TPP retries the same key, the ASPSP checks if a payment with that key already exists:

• If exists: Returns 200 OK with the existing PaymentId and status (idempotent replay).

• If not exists: Creates a new payment record and returns 201 Created.

Atomicity:
The insertion must be atomic. A SELECT followed by an INSERT is prone to race conditions (two requests inserting the same key concurrently). The solution is a unique constraint on the idempotency_key column. The database throws a duplicate key violation; the ASPSP catches it and returns the existing record.

Latency: The database insert (with a unique constraint check) takes ~5ms (p95). This is well within the SLA.

4.3 Payment Status Lifecycle

After submission, the payment goes through several statuses:

Webhook Notification:
When the payment status changes to AcceptedSettlementCompleted, the ASPSP sends a webhook notification to the TPP (as described in Module 5, Lesson 5.5).

PART 5: CLEARING AND SETTLEMENT LATENCY — The M/M/1 Queueing Model

After the ASPSP accepts the payment, it sends the instruction to the clearing house (e.g., Pay.UK for Faster Payments, EBA CLEARING for SEPA, or the BCB for Pix). The clearing house is a queueing system.

5.1 The M/M/1 Queueing Model

We model the clearing house as a single-server queue with:

• Arrival Rate λ (payments per second).

• Service Rate μ (payments processed per second).

• Traffic Intensity ρ = λ / μ. For stability, ρ < 1.

The Average Waiting Time (M/M/1):
W_q = (λ / μ) / (μ - λ) = ρ / (μ - λ)

Example Calculations:

*The p95 latency is approximated as W_q × 5 (exponential distribution has a heavy tail).

Conclusion: Pix is the fastest (0.1s) due to its high-capacity infrastructure. SEPA is slower (2s) due to the batch-oriented processing in some countries.

5.2 The Settlement Notification

After the clearing house settles the payment (transfers the funds), it sends a confirmation to the ASPSP. The ASPSP updates the payment status to AcceptedSettlementCompleted and sends a webhook notification to the TPP.

Latency: The settlement notification takes an additional 50ms (network RTT).

5.3 The Settlement Risk

If the clearing house fails to settle the payment (e.g., the debtor account has insufficient funds, even though the balance check passed), the ASPSP must reverse the payment and notify the TPP.

Probability of Settlement Failure: < 0.01% for major clearing systems.

PART 6: END-TO-END LATENCY BUDGET

The total time from the PSU clicking “Pay” to the TPP receiving a confirmation is:

Total:

• Pix (Brazil) : 50ms + 4s + 20ms + 100ms + 50ms = 4.22s.

• Faster Payments (UK) : 50ms + 4s + 20ms + 500ms + 50ms = 4.62s.

• SEPA (EU) : 50ms + 4s + 20ms + 2000ms + 50ms = 6.12s.

Regulatory Acceptance: PSD2 requires “immediate execution,” which is interpreted by the EBA as “within 5-10 seconds.” The SEPA latency (6.12s) meets this requirement.

The Fastest Path (Pix) : At 4.22s, the PSU experiences a near-instantaneous payment experience.

PART 7: OPERATIONAL RISK AND ERROR HANDLING

The Idempotency Conflict Response:

{
  "ErrorCode": "IDEMPOTENCY_CONFLICT",
  "ErrorDescription": "Idempotency key 'pay-001' already used with different payload.",
  "PreviousResourceUri": "/payments/pay-123"
}

The TPP’s Retry Strategy:

• If 409 Conflict: The TPP must fetch the existing payment (GET /payments/pay-123) and not retry.

• If 5xx Server Error: The TPP retries with exponential backoff (base 2, max 30s).

CLOSING — THE PAYMENT INITIATION ENGINE

The PISP flow is a complex interplay of regulatory consent, cryptographic binding, and clearing house latency. The certified practitioner must ensure that:

1. The consent creation is atomic (idempotent).

2. The SCA is dynamically linked (HMAC-SHA256 binding amount + payee).

3. The payment submission is idempotent (unique constraint on x-idempotency-key).

4. The clearing latency is monitored (using the M/M/1 model to predict p95 latency).

5. The webhook notification is delivered reliably.

Operational Risk: If the ASPSP incorrectly implements the dynamic linking (e.g., not binding the amount to the HMAC), a man-in-the-middle attacker could modify the payment details after the PSU authorizes it. This would lead to fraudulent payments and regulatory sanctions under PSD2 Article 66.

Key Takeaways:

• The PISP flow has 5 stages: Consent creation → SCA → Payment submission → Clearing → Settlement.

• The total p95 latency ranges from 4.22s (Pix) to 6.12s (SEPA) .

• Dynamic linking is mathematically proven to be secure (1/2^256 collision probability).

• Idempotency is enforced via a unique constraint on x-idempotency-key.

Transition to Lesson 6.2: Now that we can initiate payments, we must ensure that the PSU does not send money to the wrong payee. Lesson 6.2—Fund Confirmation Services (CBPII) —teaches you the Confirmation of Payee API, which verifies that the payee’s name matches the account number, reducing misdirected payments by 90%.