Introduction
The OFT and the banking industry have agreed to create a new payments capability for the UK by the end of 2007. For standing Orders, internet banking transfers and telephone transfers between banks the movement will be near real time. Currently, there is a 3-day delay between the initiation of the payment and the recipient getting the funds for these interbank transfers.
This article discusses some of the implications for operations and IT planners.
The article is split into three parts:
- The current high level proposals, decisions and timescales.
- The customer perspective.
- The IT implications in terms of the types of systems changes required.
High Level Proposal, Decisions and Timescales
The government has been concerned for some time that the clearing banks’ stranglehold on the payments systems is being exploited to bank’s advantage and is inhibiting innovation in terms of new forms of payment. In particular they are concerned that there is not a quick way of getting money to another party electronically other than via the expensive CHAPS payments system, which is not the appropriate vehicle for low value person to person or business to business payments.
The banking industry does not share the general criticism, however it acknowledged that with the growth of internet and telephone banking there is a gap in the range of payment options.
The banking industry has agreed in principle to introduce a new same day payments capability for these types of transactions and standing orders, essentially direct “credit” transactions. The 60,000 direct debit originators in the UK do not want to change their software so this will remain on a 3 day cycle. Similarly the payroll payment services will not change either as again all the many payroll services companies do not see any benefit and lots of cost.
The key design decision the banks are wrestling with at an industry level is whether to go with a “transaction/real time” based approach or whether to go with a “file of interbank transactions several times a day” based approach.
- The former is clearly oriented towards the internet banking/telephone customer and is more intuitive, “you click the button and the money disappears from your account and appears in the recipient’s account in near real time.” The system would be net settlement between banks and so to limit interbank settlement risk the size of individual transactions would have a cap (e.g. £10,000). This cap would avoid £100m CHAPS transactions being pushed through this route to avoid bank charges and money laundering checks. When this transaction based approach is applied to Standing Orders the emitting bank will have to change the output from their standing order systems from a file of payments to a stream of individual transactions.
- The latter is oriented towards the speeding up of the Standing Order cycle and so eliminating “float” that the banks “steal” from customers.
At the time of writing the most probable solution hypothesis is that banks will adopt the real time approach. How Banks Work certainly hopes this is the design adopted as it is a small step towards Real Time Accounting.
The industry is expecting to spend the last 6 months of 2005 doing design work and choosing a partner to build the central infrastructure that the new Payments system will need. It is at this point that the industry will publish the decision about real time versus several batches a day.
The 18 months starting from January 2006 are expected to be used to build the systems, both the central infrastructure and also the (significant) modifications to the banks’ own systems. The last 6 months of 2007 will be spent on industry level testing and customer communications leading up to launch for January 2008.
The Customer Perspective
As can be imagined from a proposal that has a regulatory push behind it this is an improvement in principle as far as the customer is concerned. However, the way the banks implement the new payment service (and price it) will have a big influence on its usefulness as far as the customers are concerned. There is an important bank/industry decision on pricing as shown in the table below.
Will the banks continue to offer the 3-day versions of these payments?
For telephone and internet banking payments the real time proposition is very intuitive. If you have the money it goes; if you don’t, it doesn’t Once it has gone it appears practically instantly in the other account. This is so obvious it is a wonder banks ever did anything else.
A big difference for customers using these payment types would be that the banks will almost certainly require greater levels of security to initiate the transactions; probably a two factor authentication process such as Chip and Pin or some other token based approach.
There may well be a bit more customer confusion about standing orders. The banks will launch the standing order during the day and process it from the remitting bank’s point of view a bit like a debit card transaction. The sending bank will do an available funds check and then debit the amount if there are funds or bounce the standing order payment if there are not. This may prove confusing for customers who might have assumed they had until the end of the day to credit funds via cheques, or BACS credits to cover the payment. Some banks may try to process the standing order several times during the day but if the incoming money only becomes available for use overnight then this will not stop the standing order being bounced.
Another area of difference for customers may be that to do with relationship managed customers. In today’s world the customer’s relationship manager is made aware of any payments (cheques, standing orders, internet transfers) that will “bounce” that coming night. This is sometimes called the “AM entries” process. The relationship manager can call the customer and warn him of the situation and so the customer can transfer funds to cover the amount needed or negotiate an overdraft with the relationship manager. In the real time world for Standing Orders and internet transfers this type of service will not be possible.
The new payment type may create some interesting challenges for Agency Banks as the funds availability processes are typically in their own banking systems and, while the processes for electronic payments were multi day, they could do their credit processing overnight and decide to pay or not. Now they will need more real time information from the Clearing Banks to allow them to decide whether to pay or not telephone transfers/internet transfers and standing orders.
Consequences for IT
Resources
At an industry level there is going to be a surge in demand for low value payments skills and so IT managers would be well advised to start developing/retaining these skills in the short term. At an industry level a new central infrastructure needs to be built and run (in the style of VOCA, LINK, EBA-STEP 1). This will place an industry drain on skills which will need to be mapped to developments in all the banks own payments, electronic banking and standing order systems. All the banks and the central infrastructure development will need the same sorts of skills at the same time.
Key Functional Areas Affected
Using the HBW Framework (see Banking Framework description) for more detail on the systems areas affected by this new payment instrument.
Channels
Within the channels there appear to be changes required in most areas apart from mail, ATM’s, POS, and Agents and Brokers, as customers can initiate a payment through them.
Electronic:
Internet and Corporate electronic banking channels are one of the main targets for this initiative. The biggest change will be the need to support two factor authentication in these channels (e.g. for personal internet banking which typically today relies on just passwords). There may or may not be additional changes to these channel systems, depending on whether the payment routing/scheduling functions are buried in the channel software or in some cross channel capability. (In the HBW framework we define it to be in the Core Banking Engine.)
Further complexity would get generated in these channels if
- both the 3 day and real time payment options are retained, and/or
- the real time payment option is charged for, see Customer Experience above.
The channel software would have to be modified to explain the options for the customer.
Telephone:
Here too the industry would probably need the customer to use more advanced security to make real time transfers over the phone. Thus the call centre software and processes would need to be modified to cope with some form of two factor authentication, maybe using SIM card security in mobile phones or some other form of token.
Also, as in the internet channels, the call centre software may, or may not have the payments scheduling and routing embedded within it (depending on the bank’s systems architecture). If it does this will need modification. Finally scripts for explaining charges and payments cycles will change if both the 3 day and real time payment options are retained and/or are charged for differently.
Branch:
Like the other channels, Branch systems will need to be modified to incorporate two factor authentication (which might be Chip and Pin if this is already being implemented in branches for debit card/cash transactions). Also like the telephone and Internet channels any payments scheduling and routing functionality buried in the branch platform software would need to be changed.
Product Engines
Core Banking Engine
This is the most affected area and very large development projects will be needed.
- Standing order suite re-engineering. Many banks’ oldest and least well documented systems are those related to standing orders. These fundamentally batch systems have a variety of jobs scheduled throughout the day to schedule files to BACS or to the internal accounting software. These will have to be re-engineered to generate transactions that go across the new cross industry payments infrastructure.
If the idea is to move to a transaction based approach some simplification and re-use should be possible.
- Automated Returns of Standing Orders (ARATSO) processing should become redundant.
- Existing transaction processing of payments by the emitter may be re-usable. Candidate areas for re-use may be parts of the debit card transaction authorisation processing or CHAPS/SWIFT payment processing. (Not that either will be wholly appropriate).
- Another important change for the core banking systems will be the concept of accepting an intra day credit, e.g. from an internet transfer. Today’s banking systems can deal with them up to a point (e.g. an incoming SWIFT payment updates an intra day bank balance in many banks). On the other hand many banks (and for most incoming payment types in all banks) still only accept incoming payments on a one or several day cycle (e.g. a debit card payment to a retailer leaves the payee’s account instantly but does not reach the retailer’s account until much later).
- Collection Accounts Customers and Agency Banks receive “Reconciliation Services” from Clearing Banks. In particular they receive important transaction detail in the form of electronic files or printouts which help them reconcile the payments they have received with their accounts receivables ledgers. The banks transaction narrative often contains valuable information to help them make this reconciliation (e.g. a customer reference number). Typically, it is the “BACS incoming” batch system that feeds the systems that create this reconciliation information. The new incoming transactions systems will have to trap this transaction info to pass it onto the reconciliation information system.
Other Product Engines
The mortgages, asset finance, insurance, cards product engines are all big users of the “Reconciliation Services” provided by the core banking engine. Although they administer products in the bank’s name they often have their own customer/account references (for example the credit card number). Customers when paying money into these areas will pay the money into a “bucket” account in the core banking engine. The transaction references in the reconciliation information provided by the core banking engine are used by the other product engine to work out which customer has paid money in. For example the credits into a “bucket” account for mortgage repayments will probably come from direct debits originated by the mortgage engine. The credits will have the mortgage account number in their transaction details and this will allow the mortgage engine to work out which mortgages have received a payment.
The impact on these other product engines is then dependent on two factors
- The product engines use of the “standard” reconciliation services of the core banking engine as opposed to in-house special processes.
- The degree to which the bank insulates users of reconciliation services from changes introduced by the new payments.
For example, if the credit cards division has a unique extract of payments and accounting entries from the core banking systems then there will be quite a bit of systems and business process work involved to take account of the new payment type. On the other hand, if
- the cards division uses the same reconciliation services as those provided for utility companies etc., and
- the core banking engine integrates the new payments into these reconciliation processes well, then there is no reason to require major change in any product engine other than the core banking one.
There will be some work related to charging in the core banking systems. The minimum amount will be the introduction of a new transaction type with a new charge. Considerably more work could be involved if the bank decides to charge personal customers for the new transaction type as these customers typically do not get charges for transactions and so work would be needed to do with pre-advice of charges and so-on. The charges could be extended for the provision of tokens for two factor authentication.
Industry Gateways
There will be a new payments gateway introduced that will have very demanding volume and availability service levels, akin to those of the debit card gateways or ATM gateways.
The Agency Bank’s use of the new payments creates a particular problem for the Clearing Banks.
Customer Management, Business Management
There should not be that much change in these areas. There will probably need to be extra transaction type and feeds to the MI and Fraud systems for the new payment type but not much more.
Credit Management processes should actually simplify as the decisioning on whether a payment gets made will now be based automatically on the funds available at the moment the payment is made. This is in contrast to the convoluted procedures currently in place with complex batch procedures in overnight processing for AM Entries, Out of Order Accounts and so on.
Unfortunately banks will not be able to do away with this completely because cheques and direct debits will still have multi-day cycles but the volume of items to be handled should decrease. This is more a credit and back office staff simplification than a systems improvement.
Conclusion
The new industry driven real time payments for internet banking and standing orders will cause banks’ IT departments to re-engineer their core banking systems. This will be a major area of systems development over the next few years. Will banks tolerate some scope creep and allow themselves to make a really big step towards Real Time Accounting by generating all the accounting entries intra day as well?
