pain.001 in Bank-to-Bank Space: the Relay Scenario (Bank A forwards pain.001 to the Debtor Agent)

In the relay scenario, a customer sends its pain.001 file to Bank A, but Bank A does not hold the debtor account, so it cannot debit the customer and cannot create the pacs.008 itself. Instead, Bank A acts as a relay, checking the file and forwarding the instruction to the debtor agent, which is the bank that does hold the account. This arrangement is common when a corporation has a relationship bank that provides its payment platform and a separate bank that holds its operating account in another country. The customer deals with one bank for its payment service, while the actual account and the actual debit sit with another bank. Bank A, as the relay agent, performs the first validation of the pain.001 file before it forwards anything. It checks the file format, the group header, the control sum, and the instruction details, and it screens the payment for sanctions and fraud. If the file fails at this stage, Bank A sends a pain.002 rejection directly to the customer, and the debtor agent never sees the instruction. If the file passes, Bank A forwards the pain.001 instruction to the debtor agent, either as a forwarded pain.001 or as an equivalent instruction in the format the debtor agent accepts. The forwarding preserves the end to end identification, so the payment can still be traced from the original customer instruction to the final settlement. The debtor agent receives the relayed instruction and treats it as a customer instruction, even though it arrived from another bank rather than directly from the customer. It checks the debtor account, the funds, the execution date, and its own limits, and it debits the account when all checks pass. It then creates the pacs.008 interbank message and sends it toward the creditor agent. The debtor agent sends its status reports back through Bank A, so the customer receives a pain.002 that reflects the debtor agent decision, even though the customer never dealt with the debtor agent directly. That chain of reporting is essential, because the customer needs one clear answer about its EUR 320,000 payment, not two conflicting answers from two banks. Relay creates a clear division of responsibility, and each bank must know where its responsibility starts and ends. Bank A is responsible for receiving the customer file, for first line validation, for forwarding the instruction accurately, and for passing status reports back to the customer. The debtor agent is responsible for the account, the funds check, the debit, the creation of the pacs.008, and the settlement. If Bank A forwards an instruction with a wrong amount, for example EUR 32,000 instead of EUR 320,000, the debtor agent will execute the wrong amount unless its own checks catch the error. For that reason, relay agreements define the fields each bank must check, the cut off times, and the liability when an error passes from one bank to the other. A worked relay example makes the flow concrete. A corporation based in Amsterdam holds its EUR operating account with a bank in Frankfurt, but it uses a bank in Amsterdam as its payment platform. The corporation sends a pain.001 file to the Amsterdam bank with a EUR 180,000 payment to a supplier in Turin. The Amsterdam bank validates the file, forwards the instruction to the Frankfurt bank, and the Frankfurt bank debits the EUR account, creates a pacs.008 for EUR 180,000, and sends it through SEPA clearing to the supplier bank in Turin. The Frankfurt bank reports acceptance back through Amsterdam, and the corporation receives a single pain.002 confirming that its payment was accepted and is in process.