Transitioning from paper to electronic and instant payments
Payments are undergoing rapid evolution with technological advancements and innovation from fintechs. Retail transactions are moving from cash to card and other electronic settlement mechanisms, and business-to-business settlements are moving from cheques and other paper instruments to electronic instruments. In addition, electronic settlement is progressing from daily batch processing to online, near real-time 24/7 instant payments.
Businesses can take advantage of this evolution in payments to reduce risks and improve their competitive advantage. However, when transitioning from paper-to-electronic or instant settlement, businesses will need to take note of the issues outlined below.
Beneficiary bank details are generally needed for electronic payments. It is normal to mail or hand deliver cheques so that beneficiary name and an address is all that is needed to issue cheques. Electronic payments require knowledge of beneficiary name and its bank account details.
For domestic payments, this is typically the bank name and branch code and the beneficiary bank account number. Many countries have adopted the International Bank Account Number (IBAN) format which includes country, bank, and beneficiary details in one “account number”.
More recently, many instant payment systems also enable payments to be made to mobile numbers, National Identification number and/or emails. This may be a convenient way to avoid the need to collect traditional bank details from vendors or customers. However, many businesses may not have associated their bank details with a single communications identity, or proxy. (this technology was designed for retail individuals). In recent developments in Hong Kong’s Faster Payment System (FPS) and Singapore’s Central Addressing Scheme (CAS), companies can use proxies for payments to be made to their UEN (Unique Entity Number).This is normally their company registration number.
For cross-border payments, the information typically required for transactions is the bank name and SWIFT Bank Identifier Code (BIC) as well as the beneficiary account number. In some countries, a bank branch code may also be required. Where possible, the beneficiary account number should be an IBAN.
Security of beneficiary details
An important point to note is that the security of the beneficiary details is critical. Firstly, this is personal information subject to relevant data privacy laws. Secondly, tampering with this information can result in failed or fraudulent payments, resulting in delay or loss of funds. Hence, the handling of beneficiary details must be tightly controlled. This data is normally stored in the vendor master file of most ERP systems. The vendor master file must have extremely restricted access control.
It is good practice to have one small and tightly controlled team responsible for updating the vendor master file, with senior management review and regular audit. The beneficiary details must be locked down from a data security perspective end-to-end from ERP to bank (for example, using encryption and security through the entire communications channel). Some banks offer analytical algorithms that highlight changed beneficiary data for review before releasing payments.
The process for collecting beneficiary details varies according to culture and business models. In many cases, beneficiary details are printed on vendor invoices. Sometimes it may be necessary to request beneficiary details from vendors explicitly. In any case, it is good practice to pre-advise vendors when changing settlement instruments (e.g. when transiting from cheque to electronic).
Once the beneficiary details are collected, the information must be entered into the vendor master file. Collecting and entering beneficiary details can be a large project. This may require extra resources such as temporary staff and or external headcount. Quality control and data accuracy are critical factors.
Businesses transitioning from paper-to-electronic will need to decide on how they wish to communicate with their banks. Although it may be possible to send signed paper instructions, this is very inefficient and is a common source of error and fraud. Some kind of electronic connectivity with banks is safer and much more efficient. This can be in the form of e-banking or preferably host-to-host connectivity.
In summary, here are some typical types of bank connectivity, from most secure to least secure:
- Payments via a direct connection from ERP to bank with straight through processing (STP): There is no manual intervention at all in this connection, and it relies on the security and approval within the ERP system. Connectivity is typically via SWIFT or other multi-bank connectivity providers, and sometimes via a bank’s proprietary H2H connectivity. There is no payment approval in bank or intermediate systems. (In a correctly managed procure-to-pay (P2P) process, it is the purchase order that is approved, not the payment. This is because if a legally binding purchase order has been correctly fulfilled by a vendor, that payment is a legal obligation. And in this arrangement, the vendor master file and the beneficiary details in particular are tightly controlled.)
- Payments are uploaded directly from ERP to bank and subsequently approved in bank systems such as e-banking: Connectivity in this arrangement is typically via SWIFT or other multi-bank connectivity provider and sometimes via bank proprietary H2H connectivity.
- Payments are extracted from ERP in some format and uploaded into e-banking for subsequent approval and sending to bank: This process is less efficient and creates a risk of error or fraud, especially if the file format is not strongly encrypted. For this reason, any files used to transfer payments from ERP to e-banking must be strongly encrypted and signed by the ERP so that it is not easy to manually modify or create payment files.
- Payments are keyed into e-banking manually for subsequent approval: This is extremely inefficient and very prone to error and fraud,as compared to paper instruments.
24/7, near-instant payments are becoming more common as countries migrate to current generation payment technologies. Fast payments are currently more widely adopted for retail rather than business-to-business (B2B) settlement, but we are already seeing that domestic B2B settlement is moving towards fast payment by default in many countries.
The distinction between modern ACH payments (which normally settle hourly) and fast payments (which normally settle in seconds) is not critical for traditional B2B settlements. Fast payments can help businesses to collect retail payments without offering credit to consumers – effectively replacing card and wallet settlement.
Fast payment systems are delivering value to businesses beyond improvement in settlement times to seconds; these include:
- Payment to mobile phone number and / or email – this method is very helpful for retailer or person-to-person payments
- Payment to proxy – this method enables payment to be made to an individual’s identity number or company registration number aka “proxy”. it facilitates payment without exchange of banking details and further allows the beneficiary to change collection account without changing the payer’s process.
- Payment via direct debits – this method enables a business to pull payment from a customer, thereby obviating credit risk
Instant payments clearly present an opportunity for retail businesses to improve their customer experiences and / or reduce credit risk from customers. And they will probably become common in business-to-business settlement over time, when instant payments become the default domestic settlement channel. In cases where the transition is simply following the market infrastructure evolution from ACH to instant payments, this can be much simpler. In fact, when beneficiary details remain the same, the transition may be as simple as changing the payment instrument code in electronic payment instructions.
In summary, paper-to-electronic transitions include the following steps:
- Design a secure and efficient electronic process
- Collect bank details from vendors
- Enter bank details into vendor master file
- Validate and secure bank details
- Inform vendors of new settlement process
- Start paying electronically
The steps for transitioning from electronic-to-fast payments will depend on the use case but they may include:
- Preparing a business case to support the change
- Checking that all parties agree and support the change
- Preparing the technical functionality
- Preparing the data requirements
- Go live
Simulate the benefits of transitioning from paper to electronic payments through Treasury Prism
Treasury Prism can help by calculating the cost of paper instruments and the benefit of transitioning to electronic and instant payments. Using Treasury Prism, you can quantify the potential cost savings and build a more compelling business case to move to electronic or instant payments. Click here to try it out.
The information herein is published by DBS Bank Ltd. (“DBS Bank”) and is for information only.
All case studies provided, and figures and amounts stated, are for illustration purposes only and shall not bind DBS Group. DBS Group does not act as an adviser and assumes no fiduciary responsibility or liability for any consequences, financial or otherwise, arising from any reliance on the information contained herein. In order to build your own independent analysis of any transaction and its consequences, you should consult your own independent financial, accounting, tax, legal or other competent professional advisors as you deem appropriate to ensure that any assessment you make is suitable for you in light of your own financial, accounting, tax, and legal constraints and objectives without relying in any way on DBS Group or any position which DBS Group might have expressed herein.
The information is not directed to, or intended for distribution to or use by, any person or entity who is a citizen or resident of or located in any locality, state, country or other jurisdiction where such distribution, publication, availability or use would be contrary to law or regulation.
DBS Bank Ltd. All rights reserved. All services are subject to applicable laws and regulations and service terms. Not all products and services are available in all geographic areas. Eligibility for particular products and services is subject to final determination by DBS Bank Ltd and/or its affiliates/subsidiaries.