How Does the Debtor Agent Create a pacs.008? The 5-Stage Creation Pipeline Explained

Every time a pacs.008 appears in the network, five processing stages have already run. A compliance engine has cleared the payment. A routing engine has selected the path. An interbank settlement amount has been calculated. A UETR has been assigned. The pacs.008 creation process is the output of all five stages, not the beginning of any one.

This is Part 2 of the pacs.008 Masterclass Series. Part 1 ended with Claudia’s payment captured, validated, and stored as a canonical instruction inside the debtor agent’s payment engine. Layer 1 sealed. Layer 2 empty. Layer 3 has one entry: an intake timestamp and a validation status flag. No UETR. No routing decision. No settlement date. No pacs.008.

That is where we pick up.

By the end of this article, you will know exactly which fields in a pacs.008 came directly from the customer’s pain.001, which were calculated by the bank, and which the bank generated from scratch. You will understand why InstructedAmount never changes while the interbank settlement amount is always derived. And you will have a clear framework for classifying any field in the message: direct map, pass-through, derived, bank-generated, or scheme rule.

What Happens Between the Customer Instruction and the pacs.008?

Before the message, five stages. Think of them as conditions, not steps. The pacs.008 is generated only when all five simultaneously clear. If any one is incomplete, no message is created. Not a partial draft. Not a placeholder. Nothing.

The five stages in sequence:

• Stage 1: Enrichment. The engine gathers the data it needs: BIC lookup, scheme determination, compliance screening, limit validation, regulatory enrichment.
• Stage 2: Decisioning. The engine evaluates the enrichment results and makes a business judgment: approve, reject, suspend, or challenge.
• Stage 3: Routing. The engine selects the correspondent path, determines the settlement method, and checks the cut-off time.
• Stage 4: UETR Assignment. The global tracking reference is generated. Not before compliance clearance. Exactly here.
• Stage 5: Generation. All five conditions true simultaneously. The pacs.008 is created from the canonical instruction.

Note: Some of these stages can run concurrently in practice (enrichment and initial compliance checks often parallelise). The stages define what conditions must clear, not necessarily a strict waterfall sequence. What cannot be parallelised: generation cannot begin until all five conditions are confirmed.

[VISUAL 1: Five-Stage pacs.008 Creation Pipeline ] 

Stage 1: How Does the Bank Enrich the Canonical Instruction?

Enrichment is data collection. It is not decision-making. These are different services with different owners, different SLAs, and different audit trails. The enrichment service writes to Layer 2 of the canonical instruction. It never makes a go-or-no-go judgment. That is Stage 2’s job.

BIC Lookup and Counterparty Validation

The creditor agent is customer input. Claudia did not type “Banco BPM” into her banking portal, but the moment she entered Acme’s IBAN, IT60 X054 2811 1010 0000 0123 456, she specified which bank she wanted to pay through. That choice belongs to the customer, regardless of the mechanism the bank uses to turn it into a usable, routable field value.

Two resolution paths exist. If the pain.001 carries a BIC directly, some corporate ERPs and treasury systems supply one, the bank validates it and writes it through with minimal transformation. If only an IBAN is present, as with Claudia’s payment, the engine derives the BIC from the IBAN prefix using a bank directory or BIC/IBAN mapping table: fast, deterministic, low cost. Either way, the bank is extracting the customer’s intent from data the customer provided, not inventing an agent identity from nothing.

If neither an IBAN nor a BIC is present, the engine falls back to name-and-address lookup: slower, less reliable, and sometimes requiring manual intervention. In every path, the retrieved BIC is validated. Is it live? Is it reachable on the intended rail?

For Claudia’s payment, the IBAN prefix identifies Banco BPM in Milan. The engine derives the BIC, validates reachability on the SEPA SCT rail, and writes the validated creditor agent BIC to Layer 2. The underlying instruction, pay through this bank, was customer input from the start. Only the field’s format, a routable BIC instead of an IBAN prefix, is bank-processed.

Contrast with DbtrAgt: the debtor agent BIC has no customer origin at all. Claudia never chose which of her bank’s BICs would handle the payment; the bank populates its own identity. CdtrAgt and DbtrAgt look like a matched pair of agent fields, but only one of them carries customer intent. The other is purely the bank’s own data. Claudia need not provide DbtrAgt information explicitly.

Scheme Determination

The scheme is the rulebook that governs everything downstream: settlement infrastructure, charge bearer rules, character limits for remittance fields, address format requirements. Getting scheme determination wrong cascades. Wrong scheme means wrong settlement method, wrong charge bearer value, wrong field limits, wrong address validation.

For Claudia’s payment: the engine identifies an Italian IBAN, a EUR-to-EUR transfer within SEPA reach, and locks to SEPA SCT. From this point forward, SEPA SCT rules apply to every enrichment and generation decision downstream.

Compliance Deep-Check

Three layers: sanctions screening, AML and PEP scoring, and cross-border threshold checks.

The critical implementation detail here is scope. All four party fields must be screened independently: Dbtr, Cdtr, UltmtDbtr, and UltmtCdtr. Screening only Dbtr and Cdtr is a gap. UltmtDbtr and UltmtCdtr can carry different entities with different sanction risk profiles, and both carry a screening obligation.

The compliance result is written to Layer 3 as a status flag. The enrichment service records what it found. Stage 2 decides what to do with it.

Limit Validation

Per-transaction limit check plus daily aggregate limit check. This is data gathering, not a rejection decision. The result, WITHIN_LIMITS or LIMIT_BREACH, goes to Layer 3 as a flag for Stage 2 to evaluate. The enrichment service reports. It does not act.

Regulatory Enrichment

If the pain.001 carried regulatory reporting data in RgltryRptg, it passes through unchanged. If a corridor mandates a purpose code or regulatory flag and the instruction lacks it, the enrichment service writes REGULATORY_DATA_REQUIRED to Layer 3. Stage 2 then decides whether to suspend and request the missing data or reject outright.

What Layer 2 Looks Like After Enrichment

Layer 2 now holds: validated scheme code, validated creditor agent BIC, compliance screening status, limit check flag, and regulatory enrichment flag. Layer 1 is unchanged and untouched. The customer’s instruction is exactly as it was when Claudia submitted it.

Stage 2: How Does the Decisioning Engine Evaluate the Payment?

Four outcomes, not two. Most architecture diagrams draw a binary: approve or reject. Production has four.

Outcome	Trigger	Canonical Write	pacs.008?
APPROVE	All checks clear, limits within range	decisioning_status = APPROVED	Proceeds to routing
REJECT	Sanctions hit, hard limit breach, AML threshold exceeded	decisioning_status = REJECTED	No pacs.008. Ever.
SUSPEND	Soft AML flag, missing regulatory data, manual review queue	decisioning_status = SUSPENDED + SLA timestamp	SLA clock starts. Payment waits.
CHALLENGE	Additional information required from customer	decisioning_status = CHALLENGED	Held pending customer response.

[VISUAL 2: Decisioning Matrix: four-outcome table showing each outcome (APPROVE, REJECT, SUSPEND, CHALLENGE), its trigger conditions, what the engine writes to the canonical, and the downstream consequence for pacs.008 generation]

A REJECTED payment never produces a pacs.008. Ever. The rejection notification travels back to the customer as a pain.002 customer payment status report. There is no path from REJECTED to generation.

SUSPEND and CHALLENGE create a different kind of operational problem. The payment sits in a queue. An SLA clock is running. If the SLA expires without resolution, the payment either escalates for manual review or auto-cancels depending on the bank’s configuration. Each status must be individually logged in Layer 3 with a timestamp, because that log is the evidence trail if the customer later disputes the handling.

The most important architectural distinction in this stage: enrichment adds data; decisioning makes a business judgment. They must be separate services. If you merge them, you lose the ability to answer the question: “Why was this payment held?” Was it held because the compliance screening flagged a potential match (an enrichment event), or because a compliance officer reviewed the flag and made a manual hold decision (a decisioning event)? In a merged implementation, you cannot tell. That gap becomes an audit problem.

Stage 3: How Does the Bank Route the Payment?

Routing has three outputs: a correspondent path, a settlement method, and an interbank settlement date. All three are written to Layer 2.

Correspondent Path Selection

Three paths the routing engine can take:

• Direct bilateral: The sending bank holds a direct account relationship with the creditor bank. No intermediary needed. The pacs.008 goes bank-to-bank. The IntrmyAgt fields are empty.
• Via correspondent: No direct relationship. The routing engine selects one or more intermediary agents from its correspondent banking database. IntrmyAgt1, IntrmyAgt2, and IntrmyAgt3 are populated as needed.
• Via clearing infrastructure: Both banks are participants in a shared clearing system. For SEPA SCT, that is the STEP2 infrastructure operated by EBA Clearing. [SEPA SCT]: IntrmyAgt fields are not used because both banks connect to STEP2 directly.

For Claudia’s payment routing via SEPA SCT: the Munich bank connects to STEP2, the Milan bank connects to STEP2, and no intermediary agents are needed. The path is via clearing.

For deeper context on how correspondent relationships are established and maintained, see Understanding Correspondent Banking. For the precise distinction between a correspondent bank and an intermediary agent in an ISO 20022 message, see Detailed Explanation of All Agents and Parties in an ISO Payment Message.

Settlement Method: Where SttlmMtd Is Born

This is the most misunderstood field write in the entire creation pipeline. SttlmMtd is the settlement method code in the pacs.008 Group Header. It is determined by the routing engine output. It is never from the customer instruction, never from pain.001, and never inherited from any customer-facing configuration.

The routing engine selects a correspondent path, and that path determines the settlement method: INDA, INGA, CLRG, or COVE. For Claudia’s SEPA SCT payment via STEP2: the settlement method is CLRG (ClearingSystem). That value is written to Layer 2 by the routing engine.

Settlement method detail (INDA, INGA, CLRG, COVE) is out of scope for this article. These codes define how the interbank account positions are moved and will be covered in the companion settlement series.

Cut-Off Time and IntrBkSttlmDt

Even an approved, routed payment can stall here. Every clearing and settlement rail has cut-off times for same-day processing. If Claudia’s instruction arrives at 16:02 and the SEPA SCT cut-off is 16:00, the IntrBkSttlmDt moves to the next TARGET2 business day.

This is why IntrBkSttlmDt is never a copy of ReqdExctnDt. The customer requested execution on a specific date. The bank calculates the actual settlement date from that request plus cut-off rules plus the scheme calendar. In the best case they match. In a late-arriving instruction, they do not.

Stage 4: When and How Is the UETR Assigned?

The UETR is assigned here: after compliance clearance, after routing confirmation, before pacs.008 generation. The timing is not arbitrary.

Assigning a UETR before compliance clearance creates orphaned UETRs. An orphaned UETR is a reference that appears in the SWIFT gpi tracker for a payment that was subsequently rejected or cancelled. Orphaned UETRs pollute investigation workflows, generate false positives in reconciliation queries, and create confusion for correspondents who receive tracker pings for payments that never arrived. Assign only after the decisioning outcome is APPROVED.

Two Sources

Bank-generated (standard): The debtor agent’s payment engine generates a UUID4 at this point. Cryptographically random. Globally unique. Written to Layer 2. Layer 3 records uetr_source = ‘bank’.

Corporate-supplied: Some treasury systems generate UETRs in the pain.001 before the instruction reaches the bank. SAP Treasury, Kyriba, Oracle Financials, and certain FIS configurations can do this. When the bank receives a corporate-supplied UETR, it makes one of two decisions:

• Accept and use it: canonical stores uetr_source = ‘corporate’.
• Discard and regenerate: canonical stores uetr_source = ‘bank’ AND records the original value as original_corporate_uetr. (Only allowed for channel initiations)

If the bank discards a corporate UETR without tracking the mapping, the corporate treasurer holds a reference that no longer exists anywhere in the bank’s system. That gap surfaces during payment investigations and is difficult to explain.

[CBPR+]: UETR is mandatory for SWIFT gpi tracking. Once assigned either by corporate or DbtrAgt, it is immutable across every hop in the chain. Every FI receiving the pacs.008 passes the UETR through unchanged. For the full picture of how payment identifiers work across the chain, see Payment Identifiers in ISO 20022.

What Are the Five Conditions That Must Be True Before pacs.008 Is Generated?

Five conditions must all be simultaneously true. If any one reads differently, generation does not begin.

Condition	Must Read
Compliance clearance	CLEARED
Limit check	WITHIN_LIMITS
Decisioning outcome	APPROVED
Routing + cut-off	CONFIRMED
UETR	ASSIGNED

Fields populate from three sources:

• From Layer 1 (customer data, immutable): Dbtr, Cdtr, DbtrAcct, CdtrAcct, EndToEndId, InstdAmt, Purp, RmtInf, UltmtDbtr, UltmtCdtr, RgltryRptg.
• From Layer 2 (bank enrichment): UETR, SttlmMtd, IntrBkSttlmDt, ChrgBr (scheme-applied value), CdtrAgt (customer-originated, bank-validated), DbtrAgt, IntrmyAgt1/2/3, InstgAgt, InstdAgt, InstrForNxtAgt.
• Generated at creation time: MsgId, CreDtTm, NbOfTxs, InstrId, TxId. MsgId, InstrId, and the agent identifiers regenerate at every hop; TxId is generated once by the debtor bank and then preserved unchanged for the rest of the journey.

After generation, the pacs.008 is a snapshot of the canonical instruction at that moment. The canonical does not stop. It continues to accumulate entries in Layer 3 as the payment travels through the network: confirmations, status updates, exception flags, and return information. Parts 5 through 8 of this series build on exactly that continuity.

[VISUAL 3: Canonical Instruction Final State: three-layer block diagram showing Layer 1 (customer core, sealed, blue fill), Layer 2 (bank enrichment, fully populated, green fill), and Layer 3 (internal metadata, amber fill), with the pacs.008 generated as a snapshot pointing out from the canonical]

What Are the Three Distinctions Every BA Gets Wrong?

Enrichment vs Decisioning

Enrichment collects data. Decisioning makes a business judgment from that data. They must live in separate services. The question “why was this payment held?” has two very different answers: “because compliance screening returned a potential sanctions match” (an enrichment result) versus “because a compliance officer reviewed the match and decided to manually hold it” (a decisioning event). Merged services make it impossible to distinguish the two. That distinction matters in regulatory audits.

ReqdExctnDt vs IntrBkSttlmDt

ReqdExctnDt is the customer’s instruction: “I want you to execute on this date.” IntrBkSttlmDt is the bank’s commitment to the network: “Funds will move on this date.” They are often the same. When the instruction arrives before the cut-off and the requested date is a valid settlement day, they match. When the instruction arrives late, or the requested date falls on a non-settlement day, they diverge. IntrBkSttlmDt is always derived. It is never a copied value from pain.001.

InstdAmt vs IntrBkSttlmAmt (IBSA)

InstdAmt is the customer’s instructed amount. EUR 50,000 for Claudia. It is recorded in the pacs.008 exactly as submitted, and it never changes at any point in the lifecycle. IntrBkSttlmAmt is the amount that settles between banks, calculated after FX conversion and charge bearer logic is applied.

Same currency does not guarantee they are numerically equal, and different currency guarantees they are not. FX conversion is one source of divergence; charge bearer logic is another, independent of currency entirely. If the sending bank deducts its own fee from the wire amount before transmitting, as happens under CRED/BEN, IBSA falls below InstdAmt even in a same-currency payment. In all cases they are separate fields serving separate purposes. Confusing them, or assuming IBSA is a copy of InstdAmt, is the single most common implementation error in pacs.008 development.

For a full breakdown of how OUR, SHA, and BEN charge codes affect what each party pays and receives, see Understanding Charge Codes in SWIFT Payments: OUR/DEBT, BEN/CRED, and SHA/SHAR.

How Does Bank Logic Get Fields Into a pacs.008?

Every field in a pacs.008 has a source. Knowing that source is what separates an architect who can design a correct implementation from one who is guessing. Five patterns cover every field in the message. This section defines each one and anchors it to Claudia’s payment. Part 4 of this series applies this same framework field by field, with full population rules and validation logic.

DIRECT MAP

The value is taken from pain.001 as-is, with no transformation, and written into the pacs.008 once at generation.

Claudia’s example: CdtrAcct. Acme’s IBAN, IT60 X054 2811 1010 0000 0123 456, is validated for format and then written directly into the pacs.008 without alteration.

PASS-THROUGH

The value originates with the customer and must travel the entire chain unchanged. The distinction from DIRECT MAP is about the journey, not the origin: no financial institution downstream, at any hop, may alter a PASS-THROUGH value.

Claudia’s example: EndToEndId. INV-2024-08821 is set once by the customer in her pain.001 and carried unchanged through pacs.008 and every subsequent FI in the chain, all the way to Acme’s bank. RmtInf/Ustrd works the same way, subject to a character limit, 140 under [SEPA SCT], 560 under [CBPR+], that must be checked before generation to avoid truncation.

DERIVED

The value is calculated using pain.001 data combined with bank logic: FX rates, routing output, cut-off times, or IBAN-to-BIC resolution. The customer’s intent is the input; the bank’s processing produces the final field value.

Claudia’s example: IntrBkSttlmDt, calculated from her ReqdExctnDt plus SEPA SCT cut-off and settlement calendar rules. CdtrAgt is also DERIVED in her case: Acme’s IBAN is customer input, and the bank derives a routable BIC from it.

Customer-originated does not always mean DIRECT MAP. CdtrAgt is the clearest example: the customer chose the creditor’s bank, but the field value the bank writes into the message, a validated BIC, is produced by bank processing. Treat the underlying instruction as customer intent for audit purposes, even when the field itself is classified DERIVED.

BANK-GENERATED

The value has no pain.001 equivalent. The bank creates it entirely. This category covers more than one behavior, and the distinction matters operationally:

• Generated once, then preserved: UETR and TxId. Both are created by the debtor bank at or shortly after generation and then pass through every subsequent hop unchanged.
• Regenerated at every hop: MsgId, InstrId, InstgAgt, and InstdAgt describe a specific bilateral leg, so each bank in the chain creates fresh values for its own hop.
• Per-hop, but discretionary: InstrForNxtAgt carries instructions to the next bank in the chain, not the final creditor agent. Each bank along the path may add or change it based on its own bilateral agreement with the next bank, not on any single fixed rule.
• Starts empty, accumulates: PrvsInstgAgt1/2/3 is empty when the debtor bank creates the first pacs.008. Each subsequent bank that rebuilds the message adds sending bank here, building a chain-of-custody record.

SCHEME RULE

A mandatory scheme override. The scheme’s rulebook defines the value regardless of what pain.001 carried. The ISO standard defines four ChrgBr codes: DEBT (BorneByDebtor, all charges to the debtor), CRED (BorneByCreditor, all charges to the creditor), SHAR (Shared, each side bears its own side’s charges), and SLEV (FollowingServiceLevel, apply the charge rules of the agreed service level or scheme).

Claudia’s example: [SEPA SCT] mandates SLEV in the pacs.008 ChrgBr field, regardless of whatever ChrgBr value her bank received in pain.001. SLEV then triggers the SEPA SCT service level’s own rules, which prescribe SHAR-equivalent behavior in practice.

Category	Example Field(s)	Claudia’s Payment
DIRECT MAP	CdtrAcct (IBAN)	IT60 X054 2811 1010 0000 0123 456 copied as-is, once validated.
PASS-THROUGH	EndToEndId, RmtInf/Ustrd	INV-2024-08821 carried unchanged across every hop in the chain.
DERIVED	IntrBkSttlmDt, CdtrAgt	Settlement date calculated from cut-off rules; Banco BPM’s BIC derived from Acme’s IBAN.
BANK-GENERATED	UETR, DbtrAgt, TxId	UETR assigned post-compliance; DbtrAgt is the Munich bank’s own BIC; TxId generated once, then preserved.
SCHEME RULE	ChrgBr	Overridden to SLEV because Claudia’s payment runs on SEPA SCT.

[VISUAL 4: Field Mapping Categories Cheat Sheet: five-row reference table, one row per category (DIRECT MAP, PASS-THROUGH, DERIVED, BANK-GENERATED, SCHEME RULE)]

How Is the Interbank Settlement Amount Calculated? Claudia’s EUR 50,000

Claudia’s payment: EUR 50,000 to Acme Engineering S.r.l. in Milan. Same currency on both ends, so Step 2 of the IBSA derivation is a pass-through and the FX arithmetic stays clean. Step 3 is where the real differences show up, and where IBSA can stop being EUR 50,000.

The IBSA three-step derivation:

1. Start with InstdAmt: EUR 50,000.
2. Apply FX: Same currency (EUR). No conversion. Amount stays EUR 50,000.
3. Apply ChrgBr rules: Determines whether the sending bank deducts its own fee from the wire amount before transmitting (which lowers IBSA below InstdAmt), or charges that fee separately to the debtor (which leaves IBSA equal to InstdAmt). This step is where IBSA and InstdAmt can diverge.

Only one amount is fixed across every scenario below: InstdAmt, EUR 50,000. IBSA is not fixed. Whether it equals InstdAmt or falls below it depends entirely on the charge bearer code and how each bank in the chain recovers its fee. Treating IBSA as a constant alongside InstdAmt is the exact mistake this worked example exists to correct.

[SEPA SCT] mandates SLEV for Claudia’s actual payment, so the DEBT and CRED rows below are shown for comparison only, to make the underlying mechanics visible. A real SEPA SCT pacs.008 would never carry DEBT or CRED in ChrgBr. Sending bank fee in this example: EUR 5.00. Receiving bank fee: EUR 2.50.

ChrgBr	Claudia Debited	IBSA Settles	Acme Receives	InstdAmt
SLEV / SHAR (SEPA SCT)	EUR 50,005.00	EUR 50,000.00	EUR 49,997.50	EUR 50,000
DEBT (OUR)	EUR 50,007.50	EUR 50,000.00	EUR 50,000.00	EUR 50,000
CRED (BEN)	EUR 50,000.00	EUR 49,995.00	EUR 49,992.50	EUR 50,000

SLEV / SHAR, Claudia’s actual scenario: SLEV triggers the SEPA SCT service level’s SHAR-equivalent rules. Claudia’s bank charges its EUR 5.00 sending fee separately, debited to Claudia on top of the EUR 50,000. Because that fee is charged separately rather than deducted from the wire, the IBSA leaving Claudia’s bank is the full EUR 50,000. Banco BPM then deducts its own EUR 2.50 receiving fee before crediting Acme, so Acme receives EUR 49,997.50.

DEBT (OUR), shown for comparison: Claudia’s bank would charge her for both its own fee and Banco BPM’s fee upfront, EUR 7.50 total, so the full EUR 50,000 reaches Banco BPM untouched and Acme receives the complete instructed amount. IBSA again equals InstdAmt here, because every fee is recovered separately from Claudia rather than deducted from the transfer.

CRED (BEN), shown for comparison: Claudia would be debited exactly EUR 50,000 with no fee added. But because the creditor side is meant to absorb all charges, Claudia’s own bank deducts its EUR 5.00 fee from the transfer before sending it onward. That deduction is what makes IBSA EUR 49,995.00, not EUR 50,000. Banco BPM then deducts its own EUR 2.50 fee from what it received, leaving Acme with EUR 49,992.50. This is the scenario that proves the point: IBSA and InstdAmt are not interchangeable. InstdAmt never moves. IBSA moves whenever a charge is deducted before the wire leaves the sending bank.

In a cross-currency payment (say Claudia instructed EUR 50,000 but settlement requires USD), Step 2 applies FX and IBSA would already be a different number in a different currency before any charge deduction is even considered. InstdAmt would still read EUR 50,000. Both fields coexist in the same message because both FX and charge bearer logic can independently cause IBSA to diverge from InstdAmt.

For the detailed mechanics of how amount and exchange rate fields interact in pain.001, see PAIN.001 Amount and Exchange Rate: A Complete Guide.

[VISUAL 5: IBSA Three-Step Calculation]

What Implementation Mistakes Show Up Most Often in Production?

Eight warnings drawn from the field mapping framework and production patterns. Each one represents a mistake that looks innocent in a test environment and fails in production.

1. IBSA is not a copy of InstdAmt. FX conversion in cross-currency payments causes them to diverge. So does charge bearer logic: under CRED/BEN, the sending bank deducts its fee from the wire before transmitting, which lowers IBSA below InstdAmt even when the currency never changes. Treat them as different variables in your data model, never derive one from the other by assumption.
2. SttlmMtd comes from the routing engine only. There is no pain.001 field that maps to it. Implementations that pull any customer-facing field into SttlmMtd are wrong. The routing engine owns this field.
3. EndToEndId truncation is a scheme compliance defect. Detect truncation risk at the enrichment stage, before message generation. Finding it after sending is operationally expensive.
4. UETR must be assigned after compliance clearance only. Assigning earlier creates orphaned references in the SWIFT gpi tracker. Those orphans surface during payment investigations and cannot easily be explained.
5. [CBPR+ Phase 2]: Unstructured address is deprecated. If pain.001 delivers an unstructured address, enrich to structured or hybrid at the bank layer before pacs.008 generation. Structured is preferred. Hybrid is valid. Unstructured is deprecated.
6. [SEPA SCT]: ChrgBr must be SLEV in the pacs.008. Not SHAR. Not whatever the customer submitted. SLEV. The scheme mandates it. Whatever ChrgBr the pain.001 carried, override to SLEV at the generation stage.
7. UltmtDbtr and UltmtCdtr require independent sanctions screening. They carry a separate screening obligation from Dbtr and Cdtr. Screening only the direct party fields is a compliance gap that will surface in a sanctions audit.
8. CdtrAgt is customer-originated, not bank-invented. The customer’s choice of which bank to pay through is part of immutable customer intent, even though the field’s final format, a validated BIC, results from bank processing. Treat the underlying instruction as customer data for audit purposes, and do not conflate CdtrAgt with DbtrAgt, which has no customer origin at all.

Frequently Asked Questions

Watch the full walkthrough on YouTube : https://youtu.be/FstImP92kVE Prefer video? Full walkthrough of the pacs.008 creation pipeline, including the derivation chain and Claudia’s worked example, on the PaymentTalks YouTube channel. Link above.

What You Now Know

A pacs.008 is not generated by receiving a payment instruction. It is generated when five conditions simultaneously clear: compliance screened, limits checked, decisioning approved, routing confirmed, UETR assigned. Every field in the message has a source: DIRECT MAP, PASS-THROUGH, DERIVED, BANK-GENERATED, or SCHEME RULE. InstdAmt never changes. IBSA is always derived. SttlmMtd always comes from the routing engine. ChrgBr in SEPA SCT is always SLEV.

Claudia’s EUR 50,000 is now in the network as a pacs.008 addressed to Banco BPM in Milan. Part 3 opens the message and walks through the block architecture. Part 4 goes field by field. Part 5 traces the serial chain from Munich to Milan and what happens at every hop along the way.