Introduction
In modern banking, accurate identification of the debit (payer) and credit (beneficiary) parties is crucial for smooth payment processing across global financial networks. A payment engine is responsible for handling transactions, ensuring compliance, formatting messages, and routing payments through the correct channels. However, deriving the debit and credit parties is not always straightforward, especially in correspondent banking where multiple institutions may be involved in a single transaction.
This article explores the Debit Party Derivation (DPD) and Credit Party Derivation (CPD) process across incoming, onward, and outgoing payments, explaining how payment engines determine the correct payer and beneficiary details to facilitate efficient, accurate, and compliant transactions.
Payment Engine
A payment engine is a core system used by financial institutions to process, validate, route, and settle transactions. It interacts with various payment networks (SWIFT, SEPA, RTGS, ACH, etc.), ensuring that payments are processed efficiently, accurately, and in compliance with regulatory requirements.
From a payment engine’s perspective, every transaction falls into one of three main categories:
- Outgoing Payment – A payment initiated by the bank and sent to an external party.
- Incoming Payment – A payment received by the bank for a customer or internal account.
- Onward Payment – A payment received and forwarded to another financial institution instead of being settled internally.
Each type follows a distinct processing flow within the payment engine. Let’s explore them in detail.
Outgoing Payment (Payment Sent by the Bank)
Definition
An outgoing payment is a transaction where the bank’s payment engine initiates a fund transfer from a customer’s or an internal account to an external party. The bank acts as the payer’s bank or Debtor Agent (also known as the originating bank).
Processing Flow in the Payment Engine
- Payment Initiation
- The payment is initiated by a customer, corporate client, or internal system (e.g., payroll, loan disbursement).
- The payment instruction may come through online banking, API integration, or manual entry.
- Validation & Compliance Checks
- The payment engine validates account details, available balance, and format requirements.
- Compliance checks such as sanctions screening, anti-money laundering (AML), and fraud detection are performed.
- Routing & Clearing Selection
- The system determines the best routing path based on:
- Payment type (domestic/international, low-value/high-value)
- Currency and beneficiary bank location
- Preferred clearing network (e.g., SWIFT, SEPA, Fedwire, local RTGS)
- The system determines the best routing path based on:
- Message Formatting & Transmission
- The payment engine formats the transaction into the required message standard (e.g., MT103 for SWIFT, pacs.008 for ISO 20022).
- The message is sent to the next institution, either the beneficiary bank or an intermediary/correspondent bank.
Example of an Outgoing Payment
A corporate customer at Bank A (UK) initiates a USD wire transfer to a supplier’s bank account in the US (Bank B).
- The payment engine processes this as an outgoing payment, debits the customer’s account, formats the payment as SWIFT MT103 or PACS08, and routes it via a correspondent bank.
Incoming Payment (Payment Received by the Bank)
Definition
An incoming payment is a transaction where the bank’s payment engine receives a fund transfer from an external institution, processes it, and credits the appropriate beneficiary’s account. The bank acts as the beneficiary’s bank or Creditor Agent (also called the receiving bank).
Processing Flow in the Payment Engine
- Message Reception & Parsing
- The payment engine receives a SWIFT MT103, MT202, or an ISO 20022 pacs message from an external bank.
- The system parses and validates the message format and content.
- Beneficiary Derivation & Compliance Checks
- If the beneficiary’s account is explicitly provided (59A in MT103 or Creditor section in PACS08), the system matches it.
- If only an IBAN or account number is provided, the engine derives the customer’s name from internal records.
- Compliance screening (sanctions, fraud detection) is performed before crediting.
- Credit Processing
- If all validations pass, the payment engine credits the customer’s account.
- Notifications (email, SMS, statement entry) may be triggered for the recipient.
Example of an Incoming Payment
A corporate client at Bank B (Germany) receives a SEPA credit transfer from a European customer.
- The payment engine at Bank B identifies the IBAN, validates the message, screens for compliance, and credits the funds to the customer’s account.
Onward Payment (Payment Forwarded by the Bank)
Definition
An onward payment occurs when a bank receives a payment but does not hold the beneficiary’s account and needs to forward the transaction to another financial institution for further processing. The bank acts as an intermediary or correspondent bank.
Processing Flow in the Payment Engine
- Message Reception & Validation
- The payment engine receives an MT103, MT202, or ISO 20022 pacs.008 from an external institution.
- The system checks if the bank is the final beneficiary’s institution.
- Onward Routing Determination
- If the beneficiary’s account is at another bank, the system determines the appropriate correspondent bank or final receiving bank.
- The routing logic selects SWIFT BIC, IBAN country codes, or correspondent banking arrangements.
- Reformatting & Forwarding
- The payment engine generates a new outgoing payment message (e.g., transforming MT103 → New Onward MT103 or MT103 → New Onward PACS08).
- The message is sent to the next institution in the payment chain.
Example of an Onward Payment
A bank in France (Bank A) receives a USD MT103 from a European client, but the beneficiary’s account is at a U.S. bank (Bank C).
- Bank A forwards the payment to its correspondent bank in the U.S. (Bank B).
- Bank B processes the onward payment and sends it to Bank C for final settlement.
Understanding Debit and Credit Party Derivation
What is Debit Party Derivation (DPD)?
Debit Party Derivation is the process of identifying the payer (debtor) in a payment transaction. This entity is the one from whom funds are debited. The debit party is usually identified based on:
- The originating account number or ordering customer details in the payment instruction.
- The sending institution in cases where an intermediary bank is processing the payment.
- The clearing system’s transaction details, if the payment is routed through a domestic or international network.
What is Credit Party Derivation (CPD)?
Credit Party Derivation is the process of identifying the beneficiary (creditor) in a transaction. This entity is the one to whom the funds are credited. The credit party is usually derived based on:
- The IBAN, account number, or beneficiary details provided in the payment message.
- The final receiving institution, if the transaction passes through an intermediary or via local clearing.
- The correspondent banking arrangements, in cases where the bank does not directly hold the beneficiary’s account.
Note: Credit Chain Building (which is part of Credit Party Derivation) when unable to reach the beneficiary bank is a complex concept. We will cover this topic in future articles which involves concepts like SSI, etc.
Debit and Credit Party Derivation in Different Payment Types
The process of deriving the debit and credit parties varies based on whether the transaction is an incoming, onward, or outgoing payment. Each type has unique challenges that payment engines must address.
A. Outgoing Payments (Payments Sent by the Bank)
Definition
An outgoing payment is a transaction where the bank initiates the payment by debiting a customer’s account and sending the funds to an external entity.
How the Payment Engine Derives Parties
- Debit Party Derivation (DPD):
- The system identifies the payer’s (debtor’s) account from the payment request.
- In customer payments, this is typically a retail or corporate account.
- In bank-to-bank transfers, the sending institution acts as the debit party.
- Credit Party Derivation (CPD):
- The system extracts the beneficiary details from the payment instruction.
- If the recipient bank is not directly connected, an intermediary bank is identified to forward the payment. (Credit Chain Building Concept)
- The engine determines whether the final beneficiary account is within the same bank or another institution. (Internal Bank Transfer if Same bank)
🔹 Example: A corporate client at Bank A (UK) initiates a USD SWIFT payment to a supplier at Bank B (US).
- Debit Party: Corporate customer at Bank A.
- The payment engine routes the payment via Bank A’s correspondent bank (Bank C) in the US, if Bank A does not have direct access to USD clearing.
- Credit Party:
- Bank C in the US, if payment sent via Correspondent.
- Bank B, if able to send the payment via USD Clearing
B. Incoming Payments (Payments Received by the Bank)
Definition
An incoming payment is a transaction where a bank receives funds from an external institution and credits a customer’s account.
How the Payment Engine Derives Parties
- Debit Party Derivation (DPD):
- The system identifies the ordering customer (payer) from the payment message.
- The sending bank (ordering institution) is often considered the debit party in interbank transactions. (Unless the payment is routed via Reimbursement Agents – Cover Scenario)
- If no clear sender details exist, the correspondent bank may be treated as the sender for processing purposes.
- Credit Party Derivation (CPD):
- The system matches the beneficiary details (e.g., IBAN, account number) to an internal account.
- If an exact match isn’t found, the system may apply fuzzy logic or manual review to determine the recipient.
- If the bank does not hold the final beneficiary’s account, it may trigger an onward payment (see next section).
🔹 Example: A customer at Bank B (Germany) receives a SEPA credit transfer from a business partner at Bank A (France).
- Debit Party: Bank A (France).
- Credit Party: Customer at Bank B (Germany).
- The payment engine matches the IBAN and credits the funds to the recipient’s account.
C. Onward Payments (Payments Forwarded by the Bank)
Definition
An onward payment occurs when a bank receives a payment but does not hold the final beneficiary’s account, requiring the transaction to be forwarded to another institution.
How the Payment Engine Derives Parties
- Debit Party Derivation (DPD):
- The system derives the original sender from the incoming message.
- If required, the system replaces the debit party (Sender in the Onward Payment) with itself before forwarding the payment (common in intermediary processing).
- Credit Party Derivation (CPD):
- The system identifies the next receiving bank or final beneficiary.
- If the next institution is a correspondent bank, the payment message may be reformatted accordingly.
- The engine ensures that fees, currency conversions, and routing rules are applied before forwarding the payment.
🔹 Example: A bank in France (Bank B) receives a USD Payment from a Bank in Italy (Bank A) on behalf of a corporate client but the beneficiary’s account is at Bank C (US).
- Debit Party: Bank A.
- Credit Party: Bank C.
- Onward Processing: Bank B having received the payment from Bank A forwards the payment to Beneficiary Bank C in the US.
Key Challenges in Debit-Credit Party Derivation
- Truncated or Missing Data – If a payment message lacks clear debit or credit party details, manual intervention may be required.
- Multiple Intermediaries – In correspondent banking, payments often pass through multiple banks, making party derivation more complex.
- Sanctions & Compliance – Payments must undergo screening before party details are finalized to avoid processing blocked transactions.
- Cross-Border Variations – Different regulatory requirements across jurisdictions affect how banks derive and validate payer/beneficiary details.
- Manual Interventions – When automated systems fail to derive the correct debit or credit party, manual reconciliation may delay transactions.
Key Methods of Debit/Credit Party Derivation
- Explicit Identification – If the payment message includes structured details (e.g., Debtor-Debtor Account or Creditor-Creditor Account in ISO 20022 messages), no derivation is needed.
- Account Based or Identifier Based Derivation – If only an account number (e.g., IBAN) is provided or If only Agent Identifier (e.g., BIC, Member ID) is provided, then payment engine derives the associated information using internal records for processing funds of the payment.
- Routing-Based Contextual Derivation – If the payment passes through multiple correspondent banks, then Debit and Credit party at each bank will differ though the Debtor and Creditor information remains constant in the payment message. This is complicated as derivation is impacted by the amount of information present in the Mandatory or optional Fields of the ISO (any) Payment Message.
- Manual Review & Compliance Checks – If discrepancies exist (e.g., a mismatch between the IBAN and provided beneficiary name or mismatch between Account Number and the associated BIC provided in the payment message), a bank may hold the transaction for manual verification.
Best Practices for Accurate Party Derivation in Correspondent Banking
- Use Structured Data Formats – Leveraging structured ISO 20022 fields ensures clear identification of payer and beneficiary with no ambiguity.
- Enrich Payment Messages – Banks should provide complete and correct details in the Payment message. (Debtor, Creditor, Ultimate Debtor, Ultimate Creditor, etc.).
- Automated Party Validation – STP Enhancers using third party providers/tools for name-matching and account verification can reduce errors in party derivation.
- Real-Time Compliance Screening – Automated AML/sanctions screening can help identify mismatches before payments are processed.
- Collaborate with Correspondent Banks – Maintaining clear agreements on payment message structuring and processing expectations improves accuracy.
Conclusion
Accurate Debit Party Derivation (DPD) and Credit Party Derivation (CPD) are critical for ensuring seamless payment processing across incoming, onward, and outgoing transactions within a payment engine. Each payment type presents unique challenges in party identification, especially in correspondent banking, where intermediary banks play a role in routing funds. Outgoing payments require precise identification of the payer (debit party) and recipient (credit party) before transmission, while incoming payments demand proper mapping of the beneficiary details to avoid misrouting or compliance issues. Onward payments add another layer of complexity, requiring the correct derivation of the next financial institution in the payment chain. By leveraging automated rules, reference data, and network-specific formats, payment engines ensure efficient, compliant, and error-free transactions. As global payment systems evolve, enhanced data models, ISO 20022 migration, and AI-driven reconciliation will further refine the accuracy and efficiency of party derivation in cross-border payments.
Additional Concepts to understand DPD and CPD.
Debit Authorization
Debit Authorization is a formal consent given by a payer (debtor) to a payee (creditor) or financial institution to withdraw funds from their account for a specific transaction or recurring payments.
Types of Debit Authorization
- One-Time Debit Authorization: Used for a single payment (e.g., online purchases, bill payments).
- Recurring Debit Authorization: Allows automatic withdrawals at regular intervals (e.g., monthly, yearly). Common for subscriptions, loans, insurance premiums, and utility bills.
- Preauthorized Debit (PAD) / Direct Debit Authorization: Common in ACH (Automated Clearing House) and SEPA Direct Debit payments. The payer signs an agreement allowing the payee to withdraw funds directly.
Tripartite Agreement
A Tripartite Agreement is a legal or contractual agreement involving three parties to define their respective roles, rights, and obligations in a particular transaction. It is commonly used in banking, finance, real estate, and payment systems where an intermediary facilitates an agreement between two main parties.
Key Elements of a Tripartite Agreement
- Three Parties Involved:
- Party A (First Party): The original contracting party
- Party B (Second Party): The counterparty
- Party C (Third Party): An intermediary
- Roles and Responsibilities Defined:
- Specifies who is responsible for payments, obligations, and dispute resolution.
- Ensures a smooth transaction between the two main parties with the third-party overseeing compliance.
- Legal Protection:
- Protects all parties by ensuring that obligations are legally enforceable.
Example
A multinational corporation – Debtor (Party A) signs a tripartite agreement with a Bank – Debtor Agent (Party B) and a payment processor – Forwarding Agent / Initiating Party (Party C) to allow the processor to manage cross-border payments.
Settlement Methods:
INGA – Settlement through the Instructing Agent
Definition: The settlement of funds is done in an account held by the instructing agent and then sends the instruction to the next bank in chain.
🧠 Think: “I’m instructing the payment, and I already settled the payment in my books.”
INDA – Settlement through the Instructed Agent
Definition: The settlement of funds is done via an account held by the instructed agent, after receiving the payment instruction from the Instructing Agent.
🧠 Think: “I’m the one being instructed, and I have to now settle the payment in my books.”
COVE – Cover Method
Definition: The payment message and the actual fund settlement take separate paths.
- One message (e.g., PACS08) goes to the creditor (bank) as notification (Direct message).
- A separate cover payment (often PACS09COV or CAMT54) settles the funds.
🧠 Think: “Message goes one way, money follows another route.”
CLRG – Clearing System
Definition: Settlement is handled through a clearing system, like an ACH or RTGS.
🧠 Think: “Let the clearing system take care of settlement.”
Credit Chain Building in Correspondent Banking
In Correspondent Banking, Credit Chain Building refers to the process where an Instructing Agent (a bank or financial institution initiating a payment) introduces an additional intermediary bank when it cannot directly reach the next party in the payment chain. This mechanism ensures the smooth movement of funds across different banking networks, especially in cross-border transactions.
Example Scenario:
🔹 A bank in Country A (Bank A) needs to send a payment to a beneficiary’s bank in Country C (Bank C).
🔹 However, Bank A does not have a direct correspondent banking relationship with Bank C.
🔹 To bridge this gap, Bank A routes the payment through Bank B (a correspondent bank in Country B).
🔹 Bank B then forwards the payment to Bank C, completing the transaction.
This process of introducing an additional financial institution in the payment chain is what defines Credit Chain Building in Correspondent Banking.
Why Credit Chain Building is Used in Correspondent Banking?
✔ Lack of Direct Relationships – Some banks do not have direct correspondent agreements due to geographic, regulatory, or network limitations.
✔ Regulatory & Compliance Factors – Some jurisdictions require additional layers of validation for cross-border payments.
✔ Liquidity Management – Intermediary banks provide liquidity support to ensure transaction completion.
✔ Risk Mitigation – Helps manage settlement risk when the originating bank cannot directly ensure fund delivery.
Options to Build a Credit Chain in Correspondent Banking
Building a Credit Chain in Correspondent Banking involves selecting the best path to route a payment through intermediaries when there is no direct banking relationship between the originating bank and the beneficiary’s bank. The selection of intermediary banks is based on predefined rules, reference data, and standard instructions to ensure efficiency, accuracy, and compliance.
- Standard Settlement Instructions (SSI): A predefined set of routing instructions used by financial institutions to determine how payments should be settled for specific currencies, countries, or counterparties.
- Currency and Country Correspondents: Banks maintain a list of preferred correspondent banks for different currencies and countries to optimize cross-border payments.
- Reference Data (SWIFT & Acuity Files): Reference data is a structured database of bank details, routing codes, BICs, and payment rules used to determine the best path for a transaction.
- Relationship-Based Routing (Nostro/Vostro Accounts): A bank uses its existing Nostro/Vostro accounts to determine the best intermediary for a transaction.
- Automated Routing via Payment Hubs & APIs: Modern payment hubs and APIs automate correspondent selection based on:
- AI-driven transaction routing
- Real-time clearing and settlement availability
- Fee optimization & FX conversion rates
Practical Examples – Explainer Videos
In the following videos, we will dive deeper into Debit Party Derivation (DPD) and Credit Party Derivation (CPD) with practical examples covering a wide range of real-world scenarios. These examples will illustrate how banks and financial institutions identify the payer and beneficiary in various payment flows, including cross-border transactions, intermediary bank involvement, and missing or ambiguous payment data. I will break down how party derivation works in each case, the challenges that arise, and the best practices for ensuring accuracy and compliance. Stay tuned for a detailed walkthrough of these scenarios, helping you understand how correspondent banks handle party identification in complex payment chains.
