Posts

SWIFT MT – PAYMENTS PERSPECTIVE

Image
  SWIFT MTs from a Payments Perspective In the earlier article, we saw how we as a banking community arrived at SWIFT MT message. These MT messages have been the backbone of international finance for years now. Yes, you read it right. Finance, which included payments, Trade Finance, Treasury, FX, Securities, etc.   There are different categories of MT messages for each of the categories mentioned above. There is a total of 9 + 1 categories. S0201 Out of all these categories of message we are going to focus on three main categories of MT messages Category 1 – MT1 series Category 2 – MT2 series Category 3 – MT9 series Category 1 aka. MT1 Series: This series of messages are used for customer ( of banks) initiated payments and checks. Messages from this category are used to initiate and transfer customer-related payments. Some examples of such messages are MT101 – Used by bank’s customers to initiate a payment MT103 – Used by banks to sends funds to each other MT104 – Used for Dir...

INTRODUCTION TO SWIFT

Image
  I NTRODUCTION TO SWIFT: The year was 1973, the world was changing rapidly. The United Kingdom, Denmark, and Ireland entered the European Economic Community, The first American prisoners of war were released from Vietnam, ‘The Exorcist premiered for the first time and the world of payments changed forever and for the better. Banks back then hand a big problem when trying to make international payments “Communication!!”. Banks used a technology called TELEX (Telegraphic Exchange) which was a major method of transmitting written messages between businesses. It was basically a network of teleprinters that used telegraph-based connections. Think of TELEX like a texting service that we use today so commonly but using large machines. This was even before FAX became popular. TELEX was basically the latest version of the telegram that has been in use since the 19 th  century. TELEX had several downsides. It was slow, there was no security and the worst part was that the receiver was ...

MISC PAYMENT CONCEPTS

Image
  Misc Payment Concepts Now that we have seen how payments and payment processing work in general, we can now move on to understand some payment-related terminologies with some examples. These are crucial to further our understanding of the different payment systems. SWIFT SWIFT  stands for  Society for Worldwide Interbank Financial Telecommunication . It is a co-operative of banks that provide the infrastructure and standards for the exchange of payment messages, especially in the cross-border space. SWIFT has a proprietary message type called  MT messages.  More about this in the future. A0701 SEPA SEPA  stands for   Single Euro Payments Area   which was created by the European Union to make the exchange of payment within the EU easy. SEPA deals with only payments in EURO currency. SEPA uses a version of the ISO20022 standard for the exchange of payment messages. More about this in the future. A0702 ISO20022 This is a standard published by the I...

SEPA CREDIT TRANSFER – PAYMENT TIMELINES

Image
  SEPA Credit Transfer – Payment Timelines In the past few articles, we have seen the different payment flows that constitute the major use cases of a SEPA credit transfer scheme. In this article, we will look at the time frame within which each of the messages needs to be sent and received in order to be compliant with the SEPA credit transfer rulebook. Some of them are scheme-dictated rules and the others are a matter of practice. I have talked about the scheme dictated rules. The most important day in all of this is the “D” day  which is the day in which the payment is settled and the funds are made available to the beneficiary. In practice, there are no rules for sending and receiving pain messages ie. In the customer to bank space. It really depends on the agreement between the bank and its customer so we will concentrate on the interbank space. Here is a table where I have discussed the timelines within which SEPA messages have to be exchanged. For your reference, I have...

SEPA CREDIT TRANSFER – RECALL FLOW

Image
  Sepa Credit Transfer – Recall flow : SEPA credit transfer – recall is a process through which an Originator or Originator PSP wants to cancel or get back the funds of an earlier credit transfer that was sent. Both the Originator and the Originator PSP can recall the payment for several reasons and here are some of them Originator: payment sent with incorrect information Wrong amount Payment sent to the wrong party Originator PSP: A duplicate message sent Fraudulent credit transfer message sent There are different parties in the payment chain and let us see how the different parties react to the recalls. It is important to note that when Originators initiate a recall they communicate to their PSP either via a payment message or email/phone call/branch visit. PSPs on the other hand send a message directly. Whenever an Originator initiates a recall request then it does not guarantee them the funds will be returned. There are 3 sub-flows within a recall flow: Payment not settled Posi...

SEPA CREDIT TRANSFER – RETURN FLOW

Image
  epa Credit Transfer RETURN FLOW “A ‘Return’ occurs when a SEPA Credit Transfer is diverted from normal execution after inter-PSP Settlement and is sent by the Beneficiary PSP to the Originator PSP for a SEPA Credit Transfer that cannot be executed for valid reasons” – EPC rule book. In this article we will discuss SEPA credit transfer RETURN FLOW. Basically, a return payment is sent by the beneficiary PSP if it is not able to process the original payment. A point to note here is that  the original payment must be settled at the inter-bank level . A Pacs.004 is sent by the beneficiary PSP to the originator PSP to return the funds. This pacs.004 will take the same path as the original pacs.008 but only in the opposite direction. It is also worth remembering that only a beneficiary PSP can send a Pacs.004 and not the originator PSP. So, if you (a PSP) are receiving a Pacs.004 then you are an Originator PSP. They are several reasons a beneficiary PSP may decide to return a ...

SEPA CREDIT TRANSFER – REJECT FLOW

Image
  SEPA Credit Transfer – Reject flow : Even though the happy path is the most common case, there are always exceptions and the different parties in an SCT payment chain can reject the payment due to several reasons. The status of the payment has to be conveyed to the ordering customer so that corrective action can be taken. Let us try to understand who are all the parties that can send Rejections and how they do it Reject definition:  “A ‘ Reject’  occurs when a SEPA Credit Transfer is not accepted for normal execution before inter-PSP Settlement. ” – EPC rule book. The main point to note here is that a payment is rejected before the settlement of the payment happens between banks. In case the payment is settled then the payment has to be Returned (we will get to this in the next article). Ordering bank (Originator PSP):  Upon receiving a Pain.001, the ordering bank (Originator PSP) will start processing the instruction and may decide to reject the pay...