Transaction banking - Role of a Payments Product

Transaction banking is one of the most valuable services provided by any bank to its customers. It generates a good chunk of revenue for banks and has a lot of growth potential if projected and nurtured with quality and efficiency. Services provided in transaction banking include fund transfers (both international and cross border), cash visibility by providing quality and timely reporting, cash management by providing services like zero balancing and notional accounts, forecasting tools, swaps, exposure to range of currencies and many more related facilities. Add to these core services, the global reach of a bank and excellent customer care service and one can expect a bank to gain a good traction and trust of large corporate and other customers.

But if the core transaction banking services, as mentioned above, are not ameliorated with an excellent quality, capacity, flexibility, scale and speed, banks can face a lot of challenges and may lose many of its customers in no time. SWIFT connectivity and its exposure play an important role here as it can really help banks to offer international financial messaging, trade execution, reporting and plethora of services to their customers. And better the quality of these services, better would be the trust and hence revenue for banks.

Now at the heart of these services provided by any bank, is the payments product or payments factory or payments enterprise or financial messaging product or cash management product, whatever one may call it. And these payments products play the most important role in determining the success of transaction banking services offered by any bank.

Having gained an exposure considerably on these payments product, both from the banking and corporate treasury standpoint, it would be a good idea to discuss the qualities of a payments product which a bank should aim at while offering transaction banking services to its customers.

Broadly speaking, a good payments product would offer:

1. Ability to handle and process a large volume of transactions 
2. Provide extremely secure, reliable and speedy payments flow as provided by SWIFT. Only SWIFT certified product should be considered
3. Easy integration with the  ERP, TMS or/and banking departments of a bank
4. Up to date availability of reference data and ability to update itself automatically
5. High level of STP for the payments processed
6. Easy integration with a third party service for compliance validation like OFAC etc
7. Should be scalable to connect with large number of banks, and to maintain large number of bank accounts
8. Excellent liquidity management services for itself and to its customer
9. High quality reporting for both intra day and prior day transactions in the format as desired by customers or compliance
10. Flexibility to adopt variety of message formats as and when required
11. For stable and seamless operation, disaster management processes should be as advanced as possible
12. Since banks operate in a dynamic environment , most of the product functionalities should be easily configurable by the user
13. The interface should be extremely user friendly and should be customizable to cover all the important features as required by the users
14. Customer care, trainings and technical support should be readily available by the product company
15. User access and account administration must be well structured not complicated
16. To maintain the history of actions, an excellent audit trail feature must be available for all the steps
17. Should have adequate cash management processes in place like automated zero balancing movement, direct debits, time based transactions
18. Product should have the capability to handle a lot of currencies and should be able to be integrated to live market rates and information
19. Interface should maintain the consistency to an extent that user at multiple locations throughout the globe should experience the same environment throughout
20. Product should be able to offer banks, various Cash management tools like liquidity management, swaps, forecasting etc which they can offer to their customers and generate value added revenues

There are many more requirements which could be explored as we dig into the technicalities.

However, working for a corporate treasury’s cash management product of one of the top 10 organizations of the US, gives you a lot of perspectives with regards to the transaction banking services offered by the banks and also their limitations.

There was a time when organizations used to consider banks for their preferred or partner banking based on the global reach of any bank. But we are seeing a lot of expectations shift from the corporate point of view and the kind of services, support, infrastructure, technology and issues resolution are playing determining roles for corporate giants to select their partner banks. Performance in score cards of firms have a lot of parameters to score and banks really have to be technically competent to be able to survive as the partner bank.

Moreover as we are seeing a lot of consolidation and harmonization in the payments landscape, particularly in Europe because of SEPA, it becomes increasingly important banks to be ready for the challenges which would evolve because of the open market competition.

Few of the issues which were encountered recently, due to the bank’s transaction banking product specific limitations are discussed below:

1. Payments failure because of special characters: This is one of the issues which was encountered with a major bank in Scotland. Bank’s product was not able to execute the payments having special characters in payments detail field. This is a flexibility issue of the product
2.  Insufficient/incomplete reporting because of an extra “/” in the description: This was a specific issue, again with the Scotland major bank, where in if a user is putting an extra “/” in the payments description field, the related balance reporting was received incomplete because of some truncation issues because of that “/” . This is again a flexibility or technical issue of the bank’s payments product
3. Inability of bank to re-send the balance reporting again: There are certain cases where due to some technical issues, the balance reporting is not received from the bank’s side. But many banks are able to re-send the balance reporting like MT940 electronically again. But with one of the big banks of France, this was the limitation
4. Bank rejecting payments because of character limitations:  One of the major US bank’s india branch was rejecting payments because in the payments field the character were exceeding 35 characters in a line and as per them the 2^nd line which automatically starts after 35 characters should start with “//”. This is a flexibility issue
5. Urgent and non urgent platforms: With a major bank of France, there was a scalability issue, wherein the bank was not able to migrate the accounts which it had set up on the urgent payments platform to the non urgent payments platform.
6. Batch failure issues: With SEPA migration, one of the major issue faced with the Major bank of Scotland was a complete batch failure because of one wrong payment. This caused a lot of issue for an organization and was fixed at the organization’s end rather that the bank. Again a flexibility issue
7. Balance reporting: Few banks have technical limitations on providing the balance reporting only when there are any transactions in an account. One Hungary bank has such limitation. This really hampers the cash management process of any organization
8. Only monthly paper statement: One of the France banks could only provide paper statement for the complete month after a month has ended while most of the European banks can provide the paper statement for any point of time. This is again a flexibility issue.

There are many more scenarios which keep coming up on a day to day basis and which if not proactively resolved, could seriously prove as dent in the relationship which organizations develop with their banks over a period of time.

Two major banks, one UK major and one Germany major bank, have really proved that their transaction banking product is highly resilient, flexible, scale able and easily customized as per the requirements of the customer. And these banks always secure the best ratings in the quarterly scorecards. But for many other banks, there is a lot of scope for improvement.
Suggestion to them :Try to improve on the current services with seriousness and explore your options carefully when you plan to migrate to a new product.

Thanks !!

SEPA - A road less travelled

SEPA as simple it may sound as a concept, is increasingly becoming complex at strategic and technical level both for banks as well as corporates. And understandingly so, as it’s not an easy ask for any organization to convert or update its legacy system to something which is quite different and new. The rather strict deadline this time by the ECB and the historically lethargic behavior of few banks and corporate regarding this initiative has made things even more worse.

And now, with the deadline looming so close, things are becoming even more challenging and rather riskier as the probability of banks taking extreme or missteps is becoming stronger.

Both at the bank level and at the organizational level, things have gathered speed and various projects are underway to implement SEPA with in time.

Let us discuss few of the issues which have been experienced so far from the organizational side:

To start with, for a payment message to be eligible for SEPA, it has to stick to few general defined set of criteria such as:

1. Payment is in EURO currency
2. Payment is made with in the countries falling under SEPA region
3. Payment is non urgent
4. Both the sides have IBAN in account field
5. Charges are shared
6. Clearing code is SWIFT

If these checks are positive for any payment, it should be made in XML ISO 20022 format.

This is the core logic which is being set up at the architecture level for most of the institutions. And the work is being done mostly using the following two approaches:

1.  Banks converting, repairing and enriching the payments which they currently receive from their customers into ISO format based on the SEPA criteria
2. Organizations themselves are putting this process at their end for the banks with which they share high volumes

For the 1^st case discussed above, though a lot banks have been providing this service of enrichment for their customers but it is not being seen as a permanent or long term approach as the requirement for all the SEPA payments to be XML format will become a mandate in the near future. Currently this approach is being strongly advocated by the PSD but it’s not a mandate to be implemented along-side the SEPA deadline of 1^st Feb 2014. And this push by the PSD for the approach no. 2 is because of the obvious reason that to make the processes seamless and would not create any manual interference and issues which is one of the visions of SEPA. Moreover banks would also prefer this approach as this will save them a lot of operational issues which they might encounter during the enrichment process.

But all said and done, this is definitely not going to be an easiest approach because of the technical level mismatches which might exist in the payments processing systems of companies and banks.

And the success of this integration would depend largely on how flexible the systems of banks are when any issue arises because of that gap.

For the first approach, the minimum or the least which a bank expects from the businesses making payments is IBAN which is ironically the biggest challenge also as till now many organizations have not been able to fully convert their accounts to IBAN format for Euro payments. But the serious organizations should not face this issue for a very long term.

For the second approach where the organizations have implemented the XML or SEPA processor at their end, few  of the issues which have been encountered so far have been discussed below:

When the banks or for the matter of fact any institution, who have their system strongly knitted into their legacy logics and syntaxes are required to move to a new way of doing things, they are bound to throw some surprises. To be specific, banks which have been executing the payments earlier in the older format such as paymul, MT  platform have now need to execute the payments in XML format. But the transition is not that easy. Even though at during the phases of requirements gathering till testing, most of the scenarios are covered, there could be few misses which can cause a lot of issues.

Batch Failure:

One of the issues which is being encountered regularly during this migration is batch failure of transactions. Since non urgent payments are sent in batches via fileact, the syntax is not verified by SWIFT as they do for MT messages.

And in few scenarios what is seen is that even if one transaction has an incorrect or undesirable data, this could lead to failure of whole bunch of transactions in that batch. And this becomes a lot of pain for businesses as it affects their day to day operations. And these incorrect data scenarios varies from bank to bank. Few of them are:

Batch failure due to a Special characters: With SEPA in place, the way banks read the payment details which are sent the messages, is getting impacted. One of the banks, after moving on to XML format started rejecting the whole batch of payments even if one payment in that batch contained a special character which was unreadable by the bank’s system.

Batch failure due to incorrect structure : Since the XML format lays a lot of emphasis on the structure, there have been issues where the whole batch was seen to rejected by one bank, when one of the transactions from that batch had wrong structure

Batch failure due to incorrect debitor account: Though rarest of scenarios, there were few scenarios observed,  where the banks were rejected a whole batch because of one transactions carrying incorrect debitor account information.

Batch failure due to incorrect currency: Similar to the above issue but this time wrong currency in a transaction of a batch leading to whole batch failure

Inability to process two formats in parallel: This functionality is the real test of the flexibility which can be offered by the payments product of a bank. Since many organizations are in a process of converting their accounts in IBAN and are also working to implement the SEPA platforms in their system, it may so happen that the payments received by a bank in XML format but are not consisting of IBAN. And since banks would have also moved to the SEPA format in their system, it might become difficult for them to process XML payment without IBAN which is a mandatory requirement for a payment to be called as SEPA. This issue was recently encountered even though these scenarios were tested during the project phase. And  because of this issue, many payments worth millions which were without IBAN were rejected by few banks. Hence it can be said that SEPA being the most advanced form of electronic payments in the region would also expect the most advanced system to function efficiently.

Inconsistency between production and test environment: Every project before going live must go through various layers of testing to ensure that all or most of the scenarios have been tested and the results are in line with the expectations. These phases of testing are done in the test environment of the banks which is considered to be the replica of production and can be trusted. But things can go haywire if the production does not behave in the manner how test environment had performed. And this was one of the issues which was encountered during a recent SEPA implementation with one of the banks. Because of this issue, the whole project was roll backed and business had to suffer a lot of problems with their live payments.

These were few of the challenges which have been experienced so far while implementing SEPA logic in the enterprise payments product of this organization. More issues are expected to be encountered as we move forward and especially when SEPA would be a mandatory requirement for all the non urgent Euro payments after 1^st Feb 2014. The only suggestions for the banks and organization for this: Look before we leap.

 Thanks !!

SEPA-yments

The aim of this article is to give an overview of SEPA to the readers who are not very well aware about this initiative but would like to have a basic understanding of this concept.

A lot has been happening over the last few years in the payments landscape of Europe. And the driving force is one of the most adventurous project in the history of payments industry, which is known by the name SEPA or Singles Euro Payments Area. SEPA is an initiative by the European Central Bank to harmonize and standardize the standards and infrastructure of Euro electronic payments in European countries. This is considered as a gradual step after the introduction and adaptation of common currency with in European countries.

The aim of SEPA is to minimize the operational barriers for customers making payments anywhere within Europe, to expand the market for Banks to acquire customers throughout the Europe and to increase the competition amongst banks so they are able to provide high quality services and products to various customers. This would be achieved by integrating the payments infrastructure, setting up the common rules for all banks and educating the various stakeholders involved.

In SEPA, 32 countries have agreed to participate out of which 17 belong to Euro zone (which have totally adopted Euro as their primary currency) and 11 belong to non-Euro zone but Euro area (Where the primary currency is the local currency and Euro as secondary) and rest belong to European Free Trade Area.

Once implemented completely, customers would be able to make the Euro payments under the same set of legal and technical guidelines irrespective of the country from and to where the payments are made.

To achieve this target, ECB has established the Payments Service Directive (PSD) which would overlook the journey of this initiative. PSD has provided 3 set of schemes to ensure that all modes of electronic payments are brought in scope of SEPA. These are as follows:

1.       SEPA Credit Transfer: This scheme stresses that all the electronic Euro credit transfers within the SEPA region would follow the same set of technical and legal framework and customer would be able to make any cross border Euro payment just like a domestic payment

2.       SEPA Direct Debit (SDD): All the Euro currency direct debits with in the SEPA region will follow the same standards and guidelines irrespective of the country. This is valid for both B2B direct debit and all other modes (also known as core direct debit)

3.       SEPA Cards framework: To harmonize the payments landscape it is imperative that the payments made by cards should also be follow the same guidelines throughout the Europe so that customers can use their card seamlessly in any European country without going through any operational, technical and legal issues. For this PSD has issued a mandate to convert all the cards with in SEPA region into EMV (Europay Master Card) enabled Chip and Pin card which could be used without any additional charges across the SEPA region

For these schemes to materialize, one of the biggest requirement from the technical perspective is the mandate for all the banks and financial institutions in SEPA region to adopt the ISO 20022 XML format for all the non urgent ACH Euro payments. This is also one of the biggest challenge for many banks because till now they have been operating on their legacy payment message formats such as SWIFT certified MT messages, Paymul messages, BAI etc. Also it would be mandatory that all the Euro payments should include IBAN after SEPA, hence banks have to work religiously to ensure that they have IBANs available for all the account numbers.

Apart from this, the clearing and settlement mechanism for the Euro payments has been integrated to one common platform called STEP2 or PE-ACH (Pan European automated Clearing House).

For all the 3 schemes the regulatory body has come out with exhaustive rule books which would explains the requirements, purpose, standards and guidelines in detail for all the stakeholders.

SEPA has been a long journey till now and despite all the efforts by ECB and other regulatory bodies, it has not been fully adopted or understood by all the countries and banks. Though in the past, despite setting up the deadlines for implementing SEPA schemes, many banks have missed those frequently and to ensure its seriousness in future, the PSD has given the non-negotiable timeline of 1^st February 2014 to fully implement SEPA SCT and SDD by all the Eurozone countries. And by 1^st Feb 2016 for all the non-Eurozone countries.

Progress: As per the latest report released by ECB, the migration rate for SEPA credit transfer has been  around 58 % and SEPA Direct Debit has been around 7%. This indicates that the efforts are more concentrated on SCT than SDD by the stakeholders and it is expected that the deadline of 1^st Feb 2014 for SDD could be missed again this time.

To summarize again:

1.  SEPA is an initiative by European Central bank to harmonize the payments landscape of Europe
2. SEPA’s mission is to ensure that all the Euro payments made in European countries are free of any domestic regulation and follow the same standards throughout
3.  SEPA will greatly reduce payments charges and operational issues for customers and increase the market and competition amongst banks. It would be a win-win situation for all
4. There would be an integrated clearing and settlement body for all the SEPA transactions and this is called as STEP2 or PE-ACH
5. Total of 34 countries are participating in SEPA
6. SEPA consists of 3 major schemes namely SEPA Credit Transfers, SEPA Direct Debit and SEPA Cards Framework
7. A payment would be classified as a SEPA payment when it is in ISO 20022 XML format, it is non urgent, the currency is Euro, both the debter and creditor have accounts in the banks in European countries, payment has IBAN for both the debit and credit account, clearing code is SWIFT and its charges are shared
8. The target date by the banks and financial institutions to fully migrate SEPA standards is 1^st Feb 2014 for th Euro zone countries and 1 Feb 2016 for non Euro zone countries
9. Apart from this BIC would not be a mandatory requirement for cross border payments after 1^st Feb 2016 and for national payments after 1^st Feb 2014
10. So far around 58% of the payments have migrated to SCT and around 7% to SDD

More on SEPA technicalities coming soon..

International Payments

While there could be various modes of payments as discussed in the last article but the landscape becomes complicated when it comes to making payments internationally. Think of a person or an organization in Mauritius wishing to make a payment worth a million dollar to another organization in Canada. The 1^st thought that could strike anyone’s mind is: This can be done easily by internet banking as we do for our day to day transactions. But this is easier said than done. If a person in India, having an account with say ICICI bank Mumbai wants to transfer an amount to an account in HDFC bank Delhi, this can be done via internet banking quite easily because the clearing and settlement for this would done with in India. For example if Mr. A has a bank account with ICICI bank and he wants to transfer INR 1000 to the account of Mr. B at HDFC bank, he can do it electronically by adding the account of Mr. B in his dashboard and then initiate the transaction. Since all the banks eligible for electronic bank are registered with Central bank of India (RBI), the netting of the amounts would be managed by it and hence clearing and settlement is not so complicated.

Domestically payments can be made through RTGS system where the settlement is done on a real time basis ie without any delay. RTGS is generally allowed only for large transactions (more than 2 lacs) Whereas in NEFT mode, the small amounts are settled in batches and it takes some time for actual funds to get transferred.

Both these modes are managed by RBI and complications are limited.

But when it comes to global transaction banking, there are many complications involved, such as:

• Different Currency
• Different clearing systems
• Different payment messages format
• Different Regulations by countries
• Different cut off timings of clearing systems
• Different in Banking relationships 

The answer to all these complications would have been a centralized body or platform which could transmit the information between banks/stakeholders in different countries by communicating with them on a real time basis and in a secure and reliable manner.

Keeping in mind the above requirements, a body called SWIFT (Society of Worldwide Interbank Financial Telecommunication) was established in 1973 with the aim of communicating and transmitting financial/system/business related messages in a secure, speedy and reliable manner. With around 10000 banks, financial institutions and corporates in around 212 countries, SWIFT had been adopted as a centralized body for passing on the financial and business messages across the globe and has been established a lot of trust among banks, businesses and other financial institutions.

One can say that SWIFT has, in a way, greatly accelerated the concept of globalization since its inception and billions of messages are processed by it on daily basis in a secure and reliable manner.

Thought SWIFT has plethora of services to offer to its stakeholders, at its core it provides 3 main services: FIN, Fileact and Interact.

FIN is a service provided by SWIFT which makes sure that a particular format (MT type) of message is validated for the standards on a real time basis and is transmitted by it a highly secure, speedy and reliable manner. MT messages are categorized into 10 business services which are further divided into different message types. 3 digit numeric code in front of MT identifies a particular business service and its sub category. For example MT103 is a single customer message as it falls in 1^st business service of customer initiation messages and 3^rd sub category of single customer message.

Each message type has a defined set of format which contains a relevant set of information and which could be easily read, understood and executed by the receiver of that message. For each MT messages transported, SWIFT charges a service charge just like we pay for calls which we make from our mobile phones.

Apart from the FIN or MT messages there exist numerous other formats like XML, Paymul, BAI , which are not validated by SWIFT. But these types can be easily transmitted by SWIFT with the help of its second service called Fileact. In this service, SWIFT allows banks to transport any file of upto 250 MB in a secure and reliable manner. SWIFT does not authenticate or validate these files and its only purpose is to transport it from one party to another. Banks and institutions can save a lot on the transmission fees as they can batch up thousands of messages in a file.

And the third and the most recent service offered by is InterAct which allows the real time communication between two parties. This is particular useful for large corporations and banks for their intraday liquidity management and forecasting purpose.

Apart from these 3 services, SWIFT also offers variety of other supporting tools like publishing reference data (BICs, IBANs, Currency codes, Country codes), implementation services for its products, offers training and guidance on different topics, support and guide various regulatory authorities on various issues and agendas, conducts a lot of research and publishes news, articles and whitepapers as a knowledge hub.

To conclude, international payments landscape could very well be synonymized with SWIFT as it has acted as a catalyst in integrating and standardizing the payments world and has a driving force for making the banking world more globalized, efficient and secure.

Card-iology

Payment as we know is the exchange of money (or equivalent)in return of some valuable good or service which could be provided by an individual, company or business, government etc.

Since the way the money is used has evolved over the years, the mode of payments have also seen a lot of innovation. Payment in cash was the only method when the business started. It gradually evolved in various forms such as cheques, demand drafts, account transfers and then in the modern era we saw the evolution of cards (debit and credit), internet banking and most recently mobile banking and social media payments.

In all these modern payment modes technology has a huge role to play. Payments done by cards or internet banking though look to be extremely user friendly and effortless on the surface, one cannot imagine the extremely robust, efficient and complex systems that are working at the back end to make that process smooth and error free.

Let’s discuss a brief about these processes with respect to cards before moving on to international payments.

Plastic money as we call them, have made our life so easy that we cannot imagine our life without them just like we feel it with mobile phones. The hassle of carrying money, its availability, keeping it secured, making efforts to count them, wear and tear involved have all been diminished to almost zero with the advent of cards. Today if you have the card, you have your bank with you. Debit cards give you the power to make any expense from the funds available in your account and you can get the cash almost anywhere using ATMS. And credit cards gives you the additional flexibility to make an expense which could be paid on the later basis to the card companies. Keeping aside the risk associated with them, one cannot ignore the fact that we have become totally dependent on them.

Let’s have a high level process view as to what happens one swipes the card at a merchant’s point of sale.

Suppose you are carrying a debit/credit card of ICICI bank and you make a purchase of Rs 100 from a merchant whose swipe machine is belonging to HSBC bank. This machine is connected to internet via wired of wifi connectivity. When the ICICI card is swiped in HSBC terminal machine, the 1^st thing which will happen is that the HSBC bank machine will read the data which is imbibed in the black colored magnetic stripe and more recently in the chip of the cards. It will then send this data along with the amount, to the acquiring bank (which is HSBC in this case). Depending on the network service provider of the card (Mastercard or Visa), the acquiring bank would route this data via them to the issuer bank.

Here the role of network providers is very important because these providers help in maintaining the network of banks, channeling the payment details and then reconciliation of the accounts in a secure and accurate manner.

After data has reached the issuer bank, it will validate the information of the card holder, its credit limit and accordingly pass the message (confirmed or rejected) to the acquiring bank via visa/Master card. This information is finally received at the terminal of merchant and receipt is generated for both merchant and the card user.

The power of this technology can be appreciated because of the fact that this whole process gets executed in few mili seconds. Such is the power of telecommunication and data maintainance.

Settlement is done in the following manner:

After the process has been executed, the books of merchant, acquiring bank, network providers and issuer banks get updated.

If customer has made a purchase of 100 bucks, the merchant becomes the legitimate receiver of this amount by his bank (acquirer bank ie HSBC). And HSBC has the pending balance on issuer bank, which is ICICI bank.

Since there would be many exchanges of transactions via Visa and Mastercard for both these banks, at the end of the day the settlement amount or the netted amount is informed to the respective banks by the network providers.

But the merchant is aloof to this netting process and he, after submissions of the receipts which he would have collected from various customers, receives the amount by acquirer bank in his account.

And the issuer bank is liable to pay this amount to the acquirer bank at the end of the day (calculated in netting). And finally the customer will pay this amount of 100 bucks to the issuer bank as and when his credit due date is approached.

Here, an important observations is that the merchant would not be receiving full 100 bucks form the acquirer bank. Various fees are deducted for each transactions by the acquirer bank, network provider and issuer banks. So ultimately the merchant may receive, say 98 bucks for that transactions.

But because of the easy availability of the liquidity with customers, cards are so widely popular.

Now the question arises, what is the benefit to the issuer bank (ICICI) in this case, when this bank is carrying the final risk exposure on the customer.

Credit Card companies basically earns from:

1.       Joining fees paid by customers

2.       Annual fees

3.       Interest fees in case of late payments

American Express has a unique model of operating this process. In Amex cards transactions, the network service is provided by Amex itself and because of which they are able to save a lot of fees in the process. And because of this reason, they are able to provide elite services to their customers.

This was all about the small transactions which are done by cards. What if the payment of worth millions has to be paid electronically from one country to another. This would be discussed in the forthcoming article “International Payments”.