Executive summary

There is quite a bit of talk in government and the banking industry about increasing competition.  One of the concerns is that customers find the process of switching between banks laborious and a barrier to moving, allowing banks to use inertia pricing.  The Industry Account Switching initiative launched in September 2012 was intended to address this but the vibes are that it has not had much impact.  The full assessment of the scheme is not due until 2015 but the rumblings of the need to improve account portability have started.  This paper looks at the three industry models for how account portability could be achieved, the aim being to make it even easier to switch banks.  It analyses these models from the perspective of what leverage the banks could get from the different models.

The three possible architectures for account portability are:

Model 1 – a distributed architecture for the industry; essentially one where the industry minimises change.  It only offers account number portability but does not transfer account history.

Model 2 – a more centralised architecture for the industry; this involves the banks in greater change.  This does provide a level of account transfer.

Model 3 – a distributed architecture with full account transfer based on data exchange between banks, again more change for banks.

It would appear that Model 1 is a pre-requisite for Models 2 and 3.  It is also possible that with a minor modification to the existing payment schemes, a bank could relatively independently offer account number portability; that is it could offer customers that switch to it the ability to keep their account numbers whilst other banks are not yet ready to do so.

The author can see little merit in Model 2 however Model 3 holds out the possibility for major cost savings for banks.

 

Model 1 – A/C switching with No Central Infrastructure

Essence of this model

This model has three design principles:

• All banks continue to independently own their IT systems and source them as they see fit.
• The various payment schemes’ functionality boundaries are essentially unchanged; i.e. if a scheme has a centralised infrastructure for payment routing it continues to have it and if not, it won’t.
• The sort code loses all significance from the point of view of industry payment routing and settlement.  It also loses nearly all significance from the point of view of identification of a bank (see below for constraints).

Some derived principles from this are:

• In order to guarantee sort code and account number uniqueness across the      industry, each sort code is “owned” by a bank for the purposes of new account number allocation i.e. Barclays cannot open an account with a NatWest sort code.  Furthermore this means all sort code-account number pairs would continue to comply with existing validation rules which are embedded in a lot of Corporate (BACS) user systems; e.g. via Eiger and      Bottomline software.
• Sort code-account number pairs cannot be re-used/re-issued by the sort code owning bank (as it does not know whether a switched sort code/account number has been closed or not).

The expected Design Response from banks to this will be that there will be a de-coupling of the external account number identifiers; the portable sort code and account number from an internal account number; in all likelihood an internal sort code and account number.  This internal sort code-account number pair will be invisible to customers, staff and payment schemes.  Thus every account will have two sort code-account number pairs at any one time.

Accompanying this will be some new translation functionality in the banks’ systems that converts the internal sort code and account number into an external sort code and account number whenever the account number becomes visible/exported.  The next section details the most important aspect, namely payment routing but other areas where this translation would be important are:

• Statements, advices and letters
• Internet banking and Mobile Banking Screens
• ATM screens and mini statements
• Back Office and Telephony screens
• Branch Screens and printouts
• Credit and Cheque Book Printing
• Debit card manufacture (if sort code and account number present)

Payments routing

The diagram below illustrates some key features of the way payments would work with account number portability.  In the example illustrated, a Barclays account (sort code 20 98 21 account number 98765432) has switched to NatWest.

There are three areas of payment handling illustrated, external payment routing which uses a Central Infrastructure (BACS, FP and Mobile Payments); external payment routing which does not have a Central Infrastructure (CHAPS payment); and an example of an “on us” payment; a cash deposit.

Central Infrastructure Payments

In the diagram there are three payments made that have to be routed and settled by the Central Infrastructure.

• A credit of £100 to “20 98 21 12345678”, a Barclays owned account.
• A credit of £95 to “20 98 21 98765432”; a NatWest owned account (an ex Barclays account that switched to NatWest).
• A credit of £45 to “60 22 53 92823866”; a NatWest owned account.

The Central Infrastructure does two activities; the first is payment routing.  In this new world it will not use the sort code as the routing mechanism but the combination of sort code and account number so there are changes that have to be made to associate every sort code-account number pair with a bank (i.e. not depend on the sort code to identify the bank).

The second function it carries out is settlement.  In the diagram example the scheme owes NatWest a total of £145 and Barclays £95.  It is important to note that the sort code cannot be part of the settlement process as the payments with the same sort code have been made to two different banks.  The sort code/account number combination have to be connected to some other concept (e.g. Settlement Bank ID) rather than whole sort codes being connected to a particular Bank ID.

For both Settlement and Routing purposes, the Central Infrastructure has no knowledge of any “internal” NatWest account number.  When the payments for the ex Barclays account arrive at NatWest, NatWest will have an “internal” sort code and account number which its accounting systems use.  In the diagram’s case this is 60 22 53 55667788.  This number is invisible to customers and the payment schemes.

At the NatWest end, there will have to be translation functionality in the payment gateways to convert the external sort code and account number to the internal identifier.

Non Central Infrastructure Payments

SWIFT and CHAPS payments do not have as much Central Infrastructure as BACS, etc.  In the diagram, there is a CHAPS payment of £10,000 to go to the account that was with Barclays but is now with NatWest.  It lands at Barclays because the remitter is using the old Barclays BIC and IBAN.  Barclays put the NatWest BIC on the same IBAN and send it to NatWest [1].  The assumption in this model is that Barclays do not maintain mapping tables of old and new account numbers (as from the customer’s point of view there is no new account number) but rather they know that the account has switched to NatWest so they re-route the payment to NatWest still quoting the old IBAN.

At the NatWest end, there would have to be translation functionality to convert the incoming BIC and IBAN to the internal account identifier before processing the payment into the accounting software.

On Us Payments

Many payments never leave a banking group because the remitter and beneficiary both bank with the same group.  In the diagram the example is a cash deposit of £50 using an old Barclays credit slip.  Here there has to be “translation” functionality in the branch/teller systems to convert the “external” sort code and account number (20 98 21 9876543232) to the internal sort code and account number (60 21 53 55667788).

Factors not Analysed

• SEPA
• Debit cards and BINS
• HOCAS and Agency Banks
• LINK/ATM’s
• Cheques
• Scope of the account number portability scheme (e.g. Non Money Transfer Accounts, Groups, Auto Transfers)

Variations on this Model that are Rejected

Just do Payment Routing	–     This does not achieve account number portability as customers have to deal with two account numbers.
Open up the internal systems to be able to cope with any sort code and thus don’t bother with Internal and External sort codes	–     This would require too much re-engineering of the banks’ systems (sort code-a/c no. validation rules, double entry bookkeeping enforced by sort code, reserved ranges for GL’s and suspense accounts, internal security based on sort codes, sort codes in product rules such as ISA only sort codes etc)
Only maintain a translate table for “switched” accounts	–     There may be a performance gain as in the short term only a small number of accounts need both an internal and external account number but over the years this would have to change. A fuller solution would also help with the changes that will be needed by Independent Commission on Banking legislation.

 

A variation on the idea

A bank could relatively independently make the translation functionality changes needed to offer account number portability.  This would need to be coupled with revealing to the payment systems the internal number associated with the switched account; i.e. use the existing Industry Account Switching processes with its associated payment routing but just tell the customer they can keep using their old account number.

The tweak to the Industry Account Switching process would be that the account number mapping tables (e.g. in BACS etc) would need to keep re-routing forever and not generate messages to payment originators to update their records to the use new “internal” identifier.

Whilst this change for a bank would need industry wide support, it does mean that the implementation can be phased by one bank at a time and does not require all banks to have to switch on account number portability at the same time, thus the industry would not be held up by the slowest moving bank.

 

Model 2 – A/C Switching with Central Infrastructure

Essence of the idea

The industry creates a shared account database which is a repository of all bank accounts.  Thus when a bank account is opened, the account (or at least a copy of it) is opened in the Industry database.

Once an account is opened it stays permanently in the central database until it is closed (e.g. when the owner dies).  When a customer switches from one bank to another, the account in the Central Infrastructure stays open but just has a different “owning bank” tag associated with it.

The benefits of this approach versus Model 1 from the regulator’s point of view are that:

1)    the account history is kept with the account as it switches between banks and remains accessible to the customer after the switch.

2)    the approach may help the authorities with their Resolution Agenda, whereby a failing bank could be quickly resolved with the accounts transferred to another entity.

The design response

The banks will have to undertake colossal re-engineering of their systems so as to break out the core account record from their own systems.  On the other hand, most banks compete on a variety of factors which they would have to keep in their own systems landscape:

• Credit Decisioning and Management
• Interest Rates and processing
• Product Rules and Features
• Channel Functionality (e.g. online)
• Customer Communications (e.g. statements)
• Charges

This functionality split is illustrated in the diagram below.

The principle idea is that all transactions would go from the bank to the Central Account database as no account update could be permitted without bank authorisation, be it account level transactions such as closure or freezing; or individual financial transactions such as a applying a payment.  There would be both real time and batch interfaces to reflect the different types of transaction possible; e.g. ATM withdrawals and files of interest postings.

The main idea from the payments’ routing perspective is that the payment routing would be unchanged over that in Model 1.  All payments whether via a Central Infrastructure (as illustrated in the diagram) or via schemes without a central infrastructure would be routed to the bank.  The bank would then make the Pay/Reject decisions before updates the central account records.  The payment schemes would need routing tables as described in Model 1 and illustrated in the diagram to decide whether to send a payment.

The banks are likely to keep internal versions of the external account number as in Model 1 for all the reasons described in Model 1.

There could be information feeds back out of the central system for funds checks and feeds to financial systems but it seems more likely that the banks would continue to keep an account record in their own systems:

• partly to reduce the amount of re-engineering of their systems.
• partly to reduce the critical dependence on the Central Infrastructure.

Like Model 1, sort codes would be owned by banks for new account opening (to guarantee industry uniqueness of sort code-account number pairs) and like Model 1 sort code-account number re-use would be prohibited.

Some variations on the idea

The banks in general would not want to concede much more functionality to the Central Core because their customer propositions and personalities are intrinsically tied up with their systems.  Two areas where they might be prepared to add to the Central Core are;

• KYC/Customer Static Data Maintenance. This is a very labour intensive activity with no competitive advantage.  Furthermore, this is often duplicated across banks as many people have relationships with two or more banks leading to wasted effort and increased costs across the industry.
• Payments processing.  There is little competitive advantage in payment processing and yet it is important as most interactions with a customer end up with a payment or money movement (e.g. a loan drawdown or an interest or dividend payment).

Assessment of model 2

Model 2 might superficially appear to speed up switching as it might be thought possible that accounts do not have to be set up.  However, they do in all the systems left behind within the banks, i.e.:

• A  customer record has to be created in the customer database (with associated static data, customer due diligence and marketing markers).
• Records have to be created in the charging systems, credit system, cheque book ordering systems, customer communications (e.g. paperless statements or not).
• Customer Channel ID’s and passwords have to be created such as internet logon details, ATM PIN details, etc.
• Relationships to other customers and accounts have to setup (e.g. Joint account holdings, auto transfer, etc).
• Furthermore, it is highly likely that the banks would have to set up an internal account number for each account switched.

In short it is far from clear that account switching is significantly speeded up or more automated using Model 2.  In many respects this model could be considered as an extension of Model 1 and it is far from clear what the benefits of it over model 1 are.

 

Model 3 – Data Exchange

Essence of the model

In this model the idea is that the industry achieves a high level of account portability without the relevant data entry work for banks (and consequent delays and customer work).  The idea is illustrated in the diagram below: 

In this model there is no central account utility; rather there is a massively extended data exchange between the bank that currently holds a customer’s account (Barclays in the diagram) and the new bank that the customer wants to switch to (NatWest in the diagram).

The customer would have to authorise Barclays to send NatWest enough customer data to be able to do credit scoring and KYC (so as to be able to decide whether to offer the customer an account).

Then, a bit like a/c switching today; on a particular agreed date a large account of data is transferred to the new bank; basically all the data needed to run the account:

• Customer Status, name, address, sex, age, date of birth, mobile phone numbers, email address, etc.
• Account Status, statement address, account owner’s name.
• Account History, transactions.

In many respects this model is an extension of today’s a/c switching approach; just more data gets moved.  It does however require Model 1 to be in place if the account number is to be preserved as well (the model could be implemented without account number portability; i.e. have account portability without account number portability).

There will still be aspects of the customer proposition that would be impossible to set up by account switching.  For example interest processing and mobile security is highly differentiated.  On the latter point:

• Some banks have hardware security devices.
• Some banks use specific software apps on mobile phones.
• All banks have different internet banking id and password formats and styles.

It is also unclear how feasible it would be to perpetuate the debit/ATM cards from one bank to another.

Assessment of Model 3

This model could be very interesting to the banking industry as it could dramatically reduce the labour costs of account switching; Accounts could be set up without the labour of keying / scanning in information such as mobile phone numbers and signatures.  It would require some regulatory agreement that the data from another bank could be considered “reliable” for KYC purposes and also an agreement to allow one bank to share the data with another bank.

Model 3 would also require the industry to agree a data schema for the interchange of data which would prove problematic (on the other hand there are some 3^rd party models that could be adopted).

Model 3 could also help with ICB in that it further assists the movement of accounts within banking groups which might be required (e.g. for High Net Worth customers or offshore customers).

From the perspective of Resolution Planning Model 3 is very attractive if a high volume account switching capability could be built on the infrastructure.

To extend this model to non personal customers (beyond sole traders and two party partnerships) would be quite hard because of the extra data involved in things like limited liability companies.

 

---