INTRODUCTION: THE PAYMENT’S JOURNEY FROM INITIATION TO FINALITY

In Lessons 6.1–6.5, we dissected the components of the payment initiation pipeline: consent creation, SCA, CBPII, VRP sweeps, idempotent submission, and settlement reporting. But we have not yet assembled these components into a single, unified lifecycle.

This lesson traces the complete journey of a payment, from the PSU clicking “Pay” to the final settlement confirmation. We deconstruct the payment lifecycle into 9 distinct stages, each with its own status, latency, and failure modes. We map the ISO 20022 statuses (camt.054) to the OBIE payment statuses, and we design the reconciliation algorithm that matches the TPP’s records with the ASPSP’s settlement reports.

We will also quantify the probability of a payment failing at each stage, using a Markov chain model, and derive the overall success rate (which is > 99.9% for major clearing systems). Finally, we will design the exception handling for each failure scenario, including manual intervention for rejected payments.

LEARNING OBJECTIVES

  1. Trace the Complete Payment Lifecycle—defining the 9 stages: Initiated → ConsentAuthorised → PaymentSubmitted → AcceptedByASPSP → SentToClearing → ClearingProcessed → Settled → FinalConfirmation → Reported.

  2. Map the ISO 20022 Statuses to OBIE Statuses—parsing the camt.054 TxSts field (ACSC, ACSP, RJCT, PDNG) and mapping them to the OBIE v4.0 payment statuses (AcceptedSettlementCompleted, AcceptedSettlementInProcess, Rejected, Pending).

  3. Design the Reconciliation Algorithm—implementing a batch job that compares the TPP’s InstructionId with the ASPSP’s settlement report, identifying missing or mismatched payments, and generating an exception report.

  4. Model the Payment Failure Probability—using a Markov chain model, deriving the probability that a payment fails at each stage, and calculating the overall success rate (≥ 99.9%).

  5. Design the Exception Handling for Each Stage—defining the recovery actions for each failure scenario: expired consent, SCA timeout, insufficient funds, clearing rejection, and settlement delay.

  6. Quantify the End-to-End Payment Latency—summing the latencies of all 9 stages, proving that the total p95 latency ranges from 4.2s (Pix) to 6.1s (SEPA) .

PART 1: THE PAYMENT LIFECYCLE — A 9-Stage Journey

The payment moves through 9 distinct stages. Each stage has a status, a latency, and a failure probability.

text
+-----------------------------------------------------------------------+
|           PAYMENT LIFECYCLE — 9 STAGES (OBIE v4.0)                     |
+-----------------------------------------------------------------------+
|                                                                        |
|  Stage 1: INITIATED                                                    |
|  +------------------------------------------------------------------+  |
|  |  PSU clicks "Pay" on the TPP's app.                            |  |
|  |  Status: Initiated (TPP internal).                                |  |
|  |  Latency: N/A (UI interaction).                                  |  |
|  |  Failure: None.                                                    |  |
|  +------------------------------------------------------------------+  |
|          |                                                            |
|          v                                                            |
|  Stage 2: CONSENT_AUTHORISED                                          |
|  +------------------------------------------------------------------+  |
|  |  TPP creates consent (POST /domestic-payment-consents).           |  |
|  |  PSU authenticates via SCA.                                       |  |
|  |  Status: Authorised.                                              |  |
|  |  Latency: 50ms (consent) + 3-5s (SCA human).                     |  |
|  |  Failure: SCA timeout (30s) → Consent Rejected.                   |  |
|  +------------------------------------------------------------------+  |
|          |                                                            |
|          v                                                            |
|  Stage 3: PAYMENT_SUBMITTED                                           |
|  +------------------------------------------------------------------+  |
|  |  TPP submits payment (POST /payments).                            |  |
|  |  Status: AcceptedSettlementInProcess.                             |  |
|  |  Latency: 20ms (API + DB).                                        |  |
|  |  Failure: Idempotency conflict (409) → TPP fetches existing.      |  |
|  +------------------------------------------------------------------+  |
|          |                                                            |
|          v                                                            |
|  Stage 4: ACCEPTED_BY_ASPSP                                           |
|  +------------------------------------------------------------------+  |
|  |  ASPSP validates payment (balance, fraud).                       |  |
|  |  Status: Pending (or Accepted).                                   |  |
|  |  Latency: 50ms (fraud check).                                     |  |
|  |  Failure: Insufficient funds → Rejected.                         |  |
|  +------------------------------------------------------------------+  |
|          |                                                            |
|          v                                                            |
|  Stage 5: SENT_TO_CLEARING                                            |
|  +------------------------------------------------------------------+  |
|  |  ASPSP sends payment to clearing house (e.g., Faster Payments).   |  |
|  |  Status: AcceptedSettlementInProcess.                             |  |
|  |  Latency: 20ms (network + serialization).                         |  |
|  |  Failure: Clearing unavailable → Retry (exponential backoff).     |  |
|  +------------------------------------------------------------------+  |
|          |                                                            |
|          v                                                            |
|  Stage 6: CLEARING_PROCESSED                                          |
|  +------------------------------------------------------------------+  |
|  |  Clearing house processes the payment.                           |  |
|  |  Status: Accepted (ISO: ACSP).                                    |  |
|  |  Latency: 0.5s (Faster Payments), 2s (SEPA).                     |  |
|  |  Failure: Clearing rejects (RJCT) → Rejected.                    |  |
|  +------------------------------------------------------------------+  |
|          |                                                            |
|          v                                                            |
|  Stage 7: SETTLED                                                     |
|  +------------------------------------------------------------------+  |
|  |  Clearing house transfers the funds.                             |  |
|  |  Status: AcceptedSettlementCompleted (ISO: ACSC).                 |  |
|  |  Latency: 50ms (notification).                                    |  |
|  |  Failure: Settlement delay (rare).                               |  |
|  +------------------------------------------------------------------+  |
|          |                                                            |
|          v                                                            |
|  Stage 8: FINAL_CONFIRMATION                                          |
|  +------------------------------------------------------------------+  |
|  |  ASPSP sends webhook to TPP.                                     |  |
|  |  Status: Completed (TPP internal).                                |  |
|  |  Latency: 80ms (webhook delivery).                                |  |
|  |  Failure: TPP unreachable → Retry (backoff).                     |  |
|  +------------------------------------------------------------------+  |
|          |                                                            |
|          v                                                            |
|  Stage 9: REPORTED                                                    |
|  +------------------------------------------------------------------+  |
|  |  ASPSP includes payment in next camt.054 report.                 |  |
|  |  Status: Reported (reconciliation).                               |  |
|  |  Latency: 24h (daily batch).                                      |  |
|  +------------------------------------------------------------------+  |
|                                                                        |
+-----------------------------------------------------------------------+

PART 2: THE ISO 20022 STATUS MAPPING — From camt.054 to OBIE

The camt.054 Bank-to-Customer Payment Status Report provides the final status of the payment. The ASPSP receives this report from the clearing house.

The TxSts (Transaction Status) Enumeration:

 
 
ISO 20022 Code Description OBIE Mapping
ACSC Accepted Settlement Completed AcceptedSettlementCompleted (final)
ACSP Accepted Settlement In Process AcceptedSettlementInProcess
RJCT Rejected Rejected (final)
PDNG Pending Pending

The Parsing Algorithm:

python
def parse_camt_054(xml_string):
    root = ET.fromstring(xml_string)
    ns = {'ns': 'urn:iso:std:iso:20022:tech:xsd:camt.054.001.08'}
    tx_infos = root.findall('.//ns:TxInfAndSts', ns)
    statuses = []
    for tx in tx_infos:
        end_to_end_id = tx.find('.//ns:OrgnlEndToEndId', ns).text
        tx_sts = tx.find('.//ns:TxSts', ns).text
        statuses.append({'EndToEndId': end_to_end_id, 'Status': tx_sts})
    return statuses

The Status Update Flow:

  1. ASPSP receives camt.054 report.

  2. For each EndToEndId (which maps to the TPP’s InstructionId):

    • If TxSts = ACSC: Update payment status to AcceptedSettlementCompleted.

    • If TxSts = RJCT: Update payment status to Rejected.

    • If TxSts = PDNG: Keep as Pending; wait for next report.

  3. Send webhook notification to TPP (if status changed).

PART 3: THE RECONCILIATION ALGORITHM — Matching TPP and ASPSP Records

The TPP maintains its own database of payments (InstructionId → Amount, Payee, Status). The ASPSP provides the camt.054 report. The TPP must reconcile the two to ensure that all submitted payments have settled.

The Reconciliation Process:

  1. Extract TPP Records: SELECT * FROM tpp_payments WHERE status != 'Settled'.

  2. Extract ASPSP Report: Parse the latest camt.054 report.

  3. Match by EndToEndId (which corresponds to the TPP’s InstructionId).

  4. Identify Discrepancies:

    • Missing in ASPSP Report: Payment was submitted but not confirmed by ASPSP. This is a critical error.

    • Missing in TPP Database: ASPSP reports a payment that the TPP did not submit. This could be fraud or a duplicate.

    • Status Mismatch: TPP thinks it’s pending, ASPSP says rejected.

The Reconciliation Report:

json
{
  "reconciliation_date": "2026-08-03",
  "total_tpp_payments": 150,
  "total_aspsp_payments": 148,
  "missing_in_aspsp": [
    { "instruction_id": "pay-001", "amount": "100.00", "date": "2026-08-02" }
  ],
  "extra_in_aspsp": [
    { "end_to_end_id": "pay-999", "amount": "50.00", "date": "2026-08-02" }
  ],
  "status_mismatches": [
    { "instruction_id": "pay-002", "tpp_status": "Pending", "aspsp_status": "Rejected" }
  ]
}

PART 4: THE PAYMENT FAILURE PROBABILITY — A Markov Chain Model

We model the payment lifecycle as a Markov chain with absorbing states (Rejected, Completed). The probability of failure at each stage is:

 
 
Stage Failure Scenario Probability
Consent Authorisation SCA timeout / PSU cancels 0.5%
Payment Submission Idempotency conflict / Validation error 0.1%
Accepted by ASPSP Insufficient funds 0.1%
Sent to Clearing Clearing unavailable 0.01%
Clearing Processed Clearing rejects (RJCT) 0.1%
Settled Settlement delay 0.01%
Final Confirmation Webhook delivery failure 0.1%

Overall Success Rate:
Success = (1 - 0.005) × (1 - 0.001) × (1 - 0.001) × (1 - 0.0001) × (1 - 0.001) × (1 - 0.0001) × (1 - 0.001)
= 0.995 × 0.999 × 0.999 × 0.9999 × 0.999 × 0.9999 × 0.999 ≈ 0.991 (99.1%).

Conclusion: The overall success rate is 99.1%. The remaining 0.9% of payments fail and must be handled by exception management.

PART 5: EXCEPTION HANDLING — Recovery Actions for Each Failure

 
 
Stage Failure Scenario Recovery Action
Consent Authorisation SCA timeout PSU restarts SCA.
Payment Submission Idempotency conflict TPP fetches existing payment.
Accepted by ASPSP Insufficient funds PSU tops up account; TPP retries.
Sent to Clearing Clearing unavailable ASPSP retries (exponential backoff).
Clearing Processed Clearing rejects (RJCT) ASPSP sends webhook with rejection reason.
Settled Settlement delay ASPSP monitors and updates status.
Final Confirmation Webhook delivery failure ASPSP retries (backoff).

PART 6: END-TO-END LATENCY BUDGET

 
 
Stage Latency (p95)
1. Initiated N/A
2. Consent Authorised 50ms + 4s (SCA)
3. Payment Submitted 20ms
4. Accepted by ASPSP 50ms
5. Sent to Clearing 20ms
6. Clearing Processed 500ms (Faster Payments) / 2s (SEPA)
7. Settled 50ms
8. Final Confirmation 80ms
9. Reported N/A (batch)
Total 4.22s (Pix) to 6.12s (SEPA)

CLOSING — THE COMPLETE PAYMENT JOURNEY

The payment lifecycle is a 9-stage journey from initiation to finality. The OBIE statuses map to ISO 20022 statuses via the camt.054 report. The reconciliation algorithm ensures that the TPP’s records match the ASPSP’s records. The overall success rate is 99.1%, and the end-to-end latency is 4.2s to 6.1s.

Operational Risk: If the reconciliation algorithm detects a missing payment, the TPP must investigate immediately. A missing payment could indicate a system failure or a fraud attempt.

Transition to Lesson 6.7: With the payment lifecycle fully mapped, we now turn to the Variable Recurring Payments (VRP) Deep Dive: Consent Management and Smart Scheduling —the advanced scheduling algorithms that adapt to the PSU’s spending patterns and optimise the sweep amount.

 
 
PreviousNext