Who are SWIFT?

Overview

SWIFT is an acronym for Society for Worldwide Interbank Financial Telecommunications. Based in Belgium, it is a cooperative society who run a vast network allowing banks and financial institutions to transfer money and securities securely.

Its is important to note that SWIFT is neither a settlement network nor a clearing network, it is a messaging system which sends global payment orders to be processed by a clearing or settlement system.

SWIFT logo
SWIFT logo

SWIFTNet Network

SWIFTNet is the private, secure network used by banks and financial institutions for secure communication owned by SWIFT.

It provides a number of communication protocols which SWIFTNet members can avail of depending on their use-case.

  • InterAct – used to exchange XML financial messages such as MX and ISO20022. It is suitable for when the financial messages are processed in almost realtime and an RTGS is involved.
  • Fin – used to exchange MT and ISO 15022 message formats. Fin is a store and forward messaging system.
  • FileAct – used to exchange financial messages in batch. Financial messages are queued and then batch processed at a certain time. FileAct is not time sensitive.

Financial Messaging Standards

SWIFT provides the standards for the syntax governing the structure of financial messaging used in the network.

Two of most important standards are ISO 15022, used for securities settlement and asset servicing messaging and ISO 20022, used as a common standard for payment messaging world-wide.

SWIFT Interfaces, Software and Services

SWIFT provides a number of interfaces that members can integrate with in order to transmit their financial messages:

  • SWIFTNet Link – API to SWIFTNet. Used by all members to connect to SWIFTNet.
  • SWIFTAlliance Gateway (SAG) – Software service that connects to SWIFTNet. Faciliates other financial integrating with SWIFTNet.
  • Alliance Access (SAA) / Alliance Messaging Hub (AMH) – Messaging software which process all SWIFT message flows, such as Fin, FileAct, InterAct etc.

Pain.008 Message

The Pain.008 message initiates a direct debit and is part of the ISO-20022 message format. It is used to request single or bulk collection(s) of funds from one or various debtor’s account(s) for a creditor. It is sent by the initiating party to the forwarding agent or
creditor agent.

Pain.008 is the initiation message for the SDD message flow. You can download the Pain.008 Message Definition Report and XML Schema from here.

Pain.008 will contain one or more direct debit instructions.

Building blocks of Pain.008

GroupHeader

A Pain.008 will contain a GroupHeader which contains the common characteristics of all individual transactions included in the message.

Pain.008 GroupHeader

The GroupHeader contains the following elements:

  • Message Identification – unique identifier for the message
  • Creation Date and Time – message creation date and time
  • Number of Transactions – total number of individual payment transactions
  • Control Sum – sum of control amounts of all the transactions within the message
  • Initiating Party – initiating party that initiated the payment transaction
  • Batch Booking – indicates whether the payments in the message should be booked as a batch or individually.
  • Payment Category Purpose – category of the payment transactions

PaymentInformation

A Pain.008 will contain a PaymentInformation block which provides information on individual payment transactions within the message.

Pain.008 PaymentInformation
Payment Information

The PaymentInformation element will contain the following elements:

  • Payment Information Identification – unique identifier for the payment information
  • Payment Method – payment execution method i,e direct debit.
  • Payment Type Information – provides additional details about the type of payment
  • Requested Execution Date – provides requested date for the payment transaction execution.
  • Debtor – party initiating the payment
  • Creditor – party receiving the payment
  • Amount – currency and monetary value of the transaction
  • Remittance Information – provides additional information related to the payment

Pacs.003 Message

The creditor agent sends the Pacs.003 message to the debtor agent, either directly or through other agents and/or a payment clearing and settlement system.

The Pacs.003 is a financial institution to financial institution customer direct debit message. It can contain 1 or many customer direct debit instructions.

A creditor bank will initiate the Pacs.003 in response to a Pain.008 direct debit initiation request to collect funds from a debtor account for a creditor. You can find the XML Schema and Message Definition Report here.

Pacs.003 overview
Pacs.003 flow

The Pacs.003 will contain:

GroupHeader


All transactions in the message share a set of common elements within the GroupHeader. It will contain the following elements:

  • Message Identification – A unique identifier assigned to the entire group of payment cancellations within the message
  • Creation Date and Time – Date and time of the creation of the payment cancellation message
  • Number of Transactions – The total count of payment cancellation instructions included in the group
  • Original Group Identification – The identification of the original group of payment instructions to which the cancellation instructions belong. It links the cancellation instructions to the original payment instructions
  • Original Message Identification: The identification of the original payment instruction within the original group to be cancelled. It specifies the specific payment instruction targeted for cancellation

DirectDebitTransactionInformation

The DirectDebitTransactionInformation will contain information about each direct debit transaction.

  • Mandate Identification: A unique identifier assigned to the direct debit mandate authorizing the payment that is being canceled.
  • Creditor Scheme Identification: Specifies the scheme or system used for the direct debit payment
  • Original Debtor Account: Debtor account which the original direct debit payment debited
  • Original Creditor Account: Creditor account which the original direct debit payment credited.
  • Original Payment Information: The cancellation of the original direct debit payment includes the payment amount, payment date, and any additional payment details.
  • Cancellation Status: Indicates the status of the cancellation instruction, such as accepted, rejected, or pending
  • Cancellation Reason Information: Provides additional details or reasons for the cancellation status

Pacs.008 Message

The Pacs.008 message belongs to the Payment Clearing and Settlement family of messages. The Pacs messages are used within the bank to bank interface.

Pacs.008 is sent by the debtor agent to the creditor agent, directly or through other agents and/or a payment clearing and settlement system. It is used to move funds from a debtor account to a creditor account.

The actual movement of funds will only happen after the clearing and settlement process. Each pacs.008 will have a settlement date which is the date when the transfer will take place.

Pacs.008 message flow
Pacs.008

The XML Schema and Message Definition Report can be found here.

Building blocks of Pacs.008 Message

The Pacs.008 message comprises of 3 blocks:

  • GroupHeader – contain all the common characteristics of all transactions contained within the Pacs.008.
  • CreditTransferTransactionInformation – set of elements providing information specific to the individual credit transfer(s).
  • SupplementaryData – contains additional information that cannot be captured in CreditTransferTransactionInformation or GroupHeader blocks.

Pain.001 Message

Overview

The Pain.001 message is initiates a SEPA Credit Transfer. It is sent by an initiating party to the debtor/forwarding agent to request the transfer of money from debtor to creditor. It is the initiation message for the SCT flow.

Like all, ISO-20022 messages, Pain.001 is specified in XML.

The XML Schema and Message Definition Report can be downloaded here.

The Message Definition Report will additionally specify business rules governing the relationships between elements in the pain.001.

Pain.001 will contain one or more credit transfer instructions.

Building blocks of Pain.001 message

GroupHeader

The GroupHeader block will contain all the common characteristics of all transactions contained within the Pain.001.

GroupHeader pain.001

The most elements within the GroupHeader are:

  • MsgId – This is a unique identifier identifying all payments within the message.
  • CreDtTm – this indicates the creation date and time of the message.
  • NbOfTxs – this indicates the number of transactions contained within the message.

PaymentInformation

The PaymentInformation block will contain all the common characteristics that apply to the debit side of the payment transactions included in the credit transfer

PaymentInformation pain.001

The PaymentInformation block will contain information such as:

  • Debtor Agent – contains information about the financial agent acting on behalf of the debtor
  • Creditor Agent – contains information about the financial agent acting on behalf of the creditor.
  • Amount – specifies the value of this payment.
  • Payment Identification – unique identifier used to identify the payment transaction.
  • Remittance Information – contains additional information regarding the purpose of the payment
  • Payment Method – indicates the payment type such as Credit transfer or direct debit.
  • Payment Type Information – provides details about the purpose of the payment

SupplementaryData

The supplementary data element contains additional information not captured in PaymentInformation or GroupHeader blocks. It can include non-standardised information related to the payment.

Pain.002 Message

The Pain.002 message is a status message and is part of the Payment Initiation family of messages within ISO 20022.

It is sent by an instructed agent to the previous party in the payment chain. It is used to inform the party about the success/failure of payment request.

The definition of the pain.002 schema and its message definition report can be found here

pain.002 overview

Building blocks of Pain.002

GroupHeader – contains all the common characteristics of all transactions contained within the Pain.002. The GroupHeader will contain the following elements:

  • Message Id: A unique identifier assigned to the message group or batch.
  • Creation Date and Time: The date and time when the message was created.
  • Number of Transactions: The total count of individual transactions included in the message.
  • Initiating Party: Information about the party initiating the message such as their name, address, and account details.
  • Message Id of the original Pain.001 Message: If the pain.002 message is a response to a pain.001 message, it may contain the message identification of the original pain.001 message to which it refers.

OriginalGroupInformationAndStatus – Original group information concerning the group of transactions, to which the status report message refers to. The OriginalGroupInformationAndStatus will contain the following elements:

  • Original Message Identification: The unique identifier assigned to the original message.
  • Original Creation Date and Time: The date and time when the original message.
  • Number of Transactions: The total count of individual transactions included in the original message.
  • Initiating Party: Information about the party who initiated the original message, such as their name, address, and account details.
  • Original Message Name Identification: The identification of the original message, such as pain.001, camt.056, or other relevant message types.

OriginalPaymentInformationAndStatus – Information concerning the original payment information, to which the status report message refers.

  • Original Payment Information: Includes details about the original payment, such as the payment amount, currency, payment date, payment method, and other relevant payment-related information.
  • Payment Status: Indicates the status of the original payment, providing information on whether the payment was successfully processed, partially processed, or rejected.
  • Transaction Information: Provides additional details about the specific transaction within the original payment, such as a unique identifier for the transaction, the debtor and creditor involved, and any related payment references.

Pacs.002 Message

The Pacs.002 message is a payment status report message used in ISO 20022. It is sent by an instructed agent to the previous party in the payment chain indicating the status of the payment instruction. It will indicate whether a payment was successful or not.

The Pacs.002 can provide status information on:

  • Credit Transfer instruction
  • Direct Debit instruction
  • Cancellation requests.

The XML Schema and Message Definition Report for Pacs.002 can be downloaded from here.

Pacs.002 message
pacs.002

Building blocks of Pacs.002 Message

GroupHeader

Set of characteristics shared by all transactions in the status report. The GroupHeader contains the following elements:

  • Message Identification: A unique identifier assigned to the message group or batch for tracking and referencing purposes.
  • Creation Date and Time: The date and time when the message group or batch was created.
  • Number of Transactions: The total count of individual transactions included in the message group or batch
  • Initiating Party: Information about the party initiating the message group or batch, such as their name, address, and account details.
  • Message Identification of the original pacs.008 message

OriginalGroupInformationAndStatus

Original group information concerning the group of transactions, to which the status report message refers to. It contains the following elements:

  • Original Message Identification: The unique identifier assigned to the original message.
  • Original Creation Date and Time: The date and time when the original message was created.
  • Number of Transactions: The total count of individual transactions included in the original message.
  • Original Initiating Party: Information about the party who initiated the original message group or batch, such as their name, address, and account details.
  • Original Message Name Identification: The identification of the original message, such as pacs.008 or other relevant message types.
  • Status: The status of the original message indicating whether it was successfully processed, partially processed, or encountered any errors or rejections.

TransactionInformationAndStatus

Information concerning the original transactions, to which the status report message refers. It contains the following elements:

  • Transaction Identification: A unique identifier assigned to the transaction.
  • Payment Information: Details about the payment, such as the payment amount, currency, payment date, and other relevant payment-related information.
  • Status: The status of the transaction, indicating whether it was successfully processed, partially processed, or encountered any errors or rejections.
  • Status Reason Information: Additional information regarding the status of the transaction, providing more context or explanation for the status code or status description.

What is Clearing And Settlement?

Introduction

Clearing and Settlement is the process that takes place once a commitment to make a payment is made and the activities that occur to ensure that that payment is fully completed.

The European Central Bank defines clearing as ‘the process of transmitting, reconciling and, in some cases, confirming transfer orders prior to settlement, potentially including the netting of orders and the establishment of final positions for settlement

It defines settlement as ‘the completion of a transaction or of processing with the aim of discharging participants’ obligations through the transfer of funds and/or securities. A settlement may be final or provisional.

When a payment is initiated, the sender’s bank submits payment instructions to an interbank clearing network. This clearing network aggregates all orders for transactions from that senders bank to other banks. It also aggregates all orders to and from other banks including the senders bank.

The clearing company is then able to net all of the orders; the net amount is moved to each bank. This is known as the final position. The transaction is now said to settled.

Clearing And Settlement
Settlement and Clearing of SCT Payment

What is a clearing house?

A clearing house acts as an intermediary between a buyer and seller in a financial market. It validates and finalises the transaction ensuring that the buyer and seller meet their financial obligations.

It is important to note that a clearing house will require its members provide collateral/margin deposits. This is done that in the event of a participant bank being unable to fulfil its obligations.

Examples of well-known clearing houses are EBA Clearing and The Clearing House.

Who are direct/indirect participants?

Banks can join a clearing system as either direct or indirect participants. Direct participants have a direct connection to the CSM and exchange transactions directly with it. Indirect participants exchange transactions with direct participants who will make transactions on their behalf with the CSM.

Indirect participants open a correspondent bank account with direct participants in order to make/receive payments. Direct participants are responsible for collecting / depositing funds with their indirect participants.

The CSM acts as a single counter party for each direct participants. This means that the CSM assumes the risk in the event that one direct participant cannot fulfil its obligations.

Types of CSMs

CSMs can vary in size. For example EBA Clearing Step 2 is a Pan-European Automated Clearing House and is available throughout the Eurozone. Others are smaller, equensWorldline, offers CSM services to some but not all Eurozone countries.

Who are EBA Clearing?

EBA Clearing, https://www.ebaclearing.eu/, are a European clearing house. They own and operate payment infrastructure in euro payments in Europe.

It processes over 17 billion transactions per year. EBA Clearing owns and operates a number of payment systems such as EURO1, STEP1, STEP2 and RT1. STEP2 and EURO1 are Systemically Important Payment Systems (SIPS).

EBA Clearing

EURO1

EURO1 is a high value RTGS style net settlement system for single same day euro transactions. Payments are settled in real-time and with finality.

It is a high value payment system whose purpose is to provide provide an efficient, secure and cost-effective net settlement infrastructure, with immediate finality for all processed EURO payments.

STEP1

STEP1 processes same-day single payments for retail and commercial transactions. and are for amounts that will not introduce risk into the clearing system. Both the sending and receiving bank have a limit imposed for each transaction.

STEP1 Participants settle their daily balances via a EURO1 Participant of their choice, which acts as their settlement bank.

STEP1
How EURO1/STEP1 works

STEP2

STEP2 is a Pan-European Automated Clearing House for processing payments in euro.

It facilitates SEPA payments to over 4,800 financial institutions and is one of the key euro mass payment systems in Europe.

It also routes, clears and settles SEPA credit transfers for banks using SEPA Credit transfers

RT1 Instant Payments

The RT1 System is a real-time gross settlement payment system for the execution of SEPA Instant Credit Transfers. European banks can use RT1 for any payment in euro that is fully compliant with the SCT Inst Scheme.