Authorised Party Initiation and Financial Institution Payment Initiation

Authorised party initiation allows a party other than the debtor to send a pain.001 instruction on the debtor behalf, provided that party has been authorised to do so. The authorised party might be a payroll service provider, a treasury service company, or a subsidiary that manages payments for a parent company. The pain.001 file names the debtor whose account will be debited, and it also names the initiating party that created the file, so the bank can see that the instruction came from an authorised third party rather than from the debtor directly. Without that distinction, the bank could not tell whether a file was a legitimate delegated instruction or an unauthorised attempt to move money. The debtor agent must check the authorisation before it executes an authorised party instruction, and that check is a control, not a formality. The bank holds a mandate or an agreement that names the authorised party, the accounts it may use, the currencies it may pay in, and any amount limits that apply. If a payroll provider is authorised to pay salaries up to EUR 1,000,000 per month from a named account, a file for EUR 1,400,000 must be rejected or escalated, even if every payment in the file is a genuine salary. If the authorised party tries to pay from an account that is not in the mandate, the instruction must also be rejected. The bank reports the rejection in pain.002 with a reason code that points to the authorisation problem. Financial institution payment initiation is different, because the initiator is a financial institution rather than a customer or an authorised third party. In this form, one bank instructs another bank to make a payment, often because the instructing bank does not hold the debtor account or does not have a direct route to the creditor agent. The initiating bank sends the instruction in a pain.001 format or in an equivalent interbank format, and the receiving bank treats it as an instruction to debit a specified account and to create the onward payment. The distinction matters for reporting, because the receiving bank reports status to the initiating bank, not to the underlying customer, and the initiating bank is responsible for reporting onward to its own customer. A common example of financial institution initiation is a small bank that uses a larger correspondent bank to make payments in a currency it does not clear directly. A bank in Lisbon might instruct its correspondent bank in London to pay USD 95,000 to a beneficiary in Singapore, because the Lisbon bank holds a USD account with the London bank but has no direct USD clearing route. The London bank debits the Lisbon bank USD account, creates a pacs.008, and sends it through the correspondent chain to Singapore. The London bank reports the outcome to the Lisbon bank, and the Lisbon bank reports to its customer. Each bank in the chain knows only its own leg, which is why the end to end identification and the UETR matter for tracing the full payment. Authorised party initiation and financial institution initiation both depend on clear agreements, and both fail when the agreement is missing or unclear. The agreement must define who may initiate, which accounts may be debited, which currencies and countries are allowed, what limits apply, and how status reports will flow back. A corporation that lets a service provider initiate payments without a written mandate risks unauthorised debits, while a bank that accepts a financial institution instruction without checking the account agreement risks debiting the wrong account. In both cases, the pain.001 and pain.002 messages carry the evidence, because they record the initiator, the debtor, the account, the amount, and the status, and that record is what an auditor or an investigator will ask for first.