Faster Payments Service

Document Sample
Faster Payments Service Powered By Docstoc
					White Paper

Faster Payments Service
Impact on IT Systems and Testing for Compliance
Last Updated: 30th May, 2007

This white paper describes the Faster Payments Service (FPS) and the impact it will have on IT systems, and illustrates the approach that needs to be taken to ensuring that the organization can participate successfully in the scheme.

institutions. Some banks will be able to offer instantaneous funds transfers with the financial benefits and convenience this brings, whilst other banks will be tied to slower and less customer-friendly methods. It is strongly anticipated that customer demand will drive the uptake of FPS. In addition, non-banking organizations such as utility companies or employers will be able to use FPS to receive payments or pay salaries, for example, with greater speed and lower operating costs. Again, this will be a competitive advantage for early adopters of the service.

Intended Audience
This white paper is written for project managers and test managers who will be implementing and/or testing an internal system which connects to FPS.

What is FPS made up of?
Centrally there are three key elements of FPS:
 The financial message switch which routes transactions

History of Faster Payments Service
In 2004, the Office of Fair Trading created the Payment Systems Task Force (PSTF) and charged them with looking at common practice in the payment systems used by UK banks with a view to assessing whether these practices were in the best interests of customers. The PSTF found that it would be better for customers if balance transfers were carried out in near-real time (a matter of seconds) rather than if the current practice of allowing three to seven working days were to continue. This was considered especially true in the areas of telephone and internet banking, so it is these elements (along with some forwarddated payments such as standing orders) which are being looked at by FPS initially. APACS, the UK trade body which represents organizations that provide payment services, responded to these findings by putting out a tender for such a system. The right to provide the service was won by Immediate Payments Limited (IPL), an organization combining the message switching expertise of Link Interchange Networks Ltd (who provide the UK’s main ATM network) and the settlement expertise of Voca Ltd (who run the BACS system). The first wave of banks to implement FPS will be going live at the end of 2007, and three additional ‘joining’ dates are planned for 2008. All the initial financial organizations to join the scheme are categorized as ‘member banks’. Other companies and institutions joining the scheme may do so in that capacity, or as agencies, corporates, bureaus or third-party beneficiaries.

between members and other participants;
 The settlement engine which settles transactions with

the Bank of England;
 A reporting module which allows members or participants

to query their current status with the service. In addition, each member or participant will have a local gateway which connects to the Switch.

The Key Business Challenges of FPS
There are two key business challenges which FPS presents:
 Customers will be expecting a seamless transition

from the existing systems they use for internet and telephone banking to the FPS elements of the bank infrastructure. They will not expect or want to see any difference between using this new capability and older, existing functionality. The only thing that customers should perceive is that now their balance transfers are implemented quickly;
 There is no way to recall a transaction which has been

The Business Benefit of FPS
The existence of FPS demonstrates the ability of the financial sector to listen to the concerns of consumer bodies and respond to these concerns without the need for recourse to legislation. Now that FPS will be offered by some financial organizations to their customers this becomes a clear service differentiator versus non-FPS

sent, meaning that the organization offering FPS to their customers will have to build in sufficient verification points to ensure transactions are not sent by mistake or to the wrong receivers (although the system will help with some aspects of this).

The Key Technical Challenges of FPS
There are two key aspects of FPS which present significant technical challenges to organizations which wish to join the scheme:
App_WhitePaper_Faster_Payments_Service_1v03 Page 2 © 2007 AppLabs

 The system is fully automated: with the exception of

the reporting module, all elements of the system are automated. This brings with it all the challenges of a system interface, e.g. those messages must be formatted absolutely correctly or they will be rejected. There is no human intervention which will allow an almost-right message to be interpreted;
 The system is designed to be fast: the service level

which turns this into an FPS formatted message and sends it onwards to the Switch. Because of this, those systems must either be modified or replaced with a new application to do the job. The implementation of the gateway is the responsibility of the member or participant organization. Whilst there are highly detailed specifications for the messages which it uses to communicate with the Switch, message formats used with local systems can be defined internally. Naturally there are a range of possible outcomes for each transaction sent, including the receiving organization accepting it, accepting it with some kind of qualification or rejecting the payment. It is also possible for the transaction to fail for technical reasons. When the local systems receive these responses then they need to act appropriately and update the customer as to what has happened with the transaction they requested. Finally, the local system will have to be resilient to messages being lost or delayed; there are detailed rules for how to handle this built into the FPS scheme and the system must comply with these.

agreements for message turnarounds are tight, meaning that all the elements of the member’s or participant’s system must perform whilst experiencing heavy utilization.
 Messages are one at a time, rather than bulk as in the

traditional 3-day service: this means that systems for detecting fraud and money lending must now work on individual transactions and in real time.
 FPS means that a customer’s balance can change in

a very dynamic way through out the day: customers expect to have access to those funds so different elements of an organization’s systems must share that view dynamically, rather than consolidating their views on a periodic basis.

Financial Systems
Whilst all transactions, either sent or received, can impact the financial position of customer in this case we are specifically considering systems which implement received transactions. As has been noted earlier, it is possible to reject transactions (if, for example, the customer details are not recognized) or to accept them and possibly to accept them with a qualification. The system which receives the incoming payment must check the content of the message, make sure it can process it and then process it appropriately. The processing of the message incorporates generating the corresponding reply and also looking out for any error or follow-on messages from the Switch which relate to that transaction, such as a reversal. The most likely causes of this would be the response message being either delayed or lost in transmission, and in either case the local financial systems would need to reverse the transaction which was being enacted. In each case, the changes to the customer’s balance must be reflected in all the existing local systems in real time. This may itself present a challenge as currently it is common for different systems within an organization to have their own balance information which is only consolidated on a periodic basis.

Impact on IT Systems of Implementing FPS
The impact of FPS on existing IT systems can be split into three elements: customer facing systems, financial systems and control systems.

Customer Facing Systems
One of the major groups of IT systems which will be impacted by FPS are those which customers use to request financial transactions such as initiating a balance transfer or setting up a standing order. In each case, the local systems will have existing functionality which is still valid post-implementation of FPS, whilst other new functionality is needed to add in the FPS capability. From a customer perspective, all the FPS capabilities are around the sending of either one-off or recurring payments. Note that when a payment is recurring or forward dated then it is the responsibility of the local systems to hold on to that transaction until the time to send it arrives. When sending a payment transaction, the internal applications of the member/participant need to formulate a correctly structured message and send it to the ‘gateway’
App_WhitePaper_Faster_Payments_Service_1v03 Page 3 © 2007 AppLabs

Finally, financial institutions have an obligation to look out for money laundering or fraudulent activity, These systems currently have a 72 hour window to operate in, and can analyze a whole batch of transactions together to look for suspicious patterns of behavior. With FPS messages must be analyzed individually and in real time, which is a significant paradigm shift

 External integration and compliance testing will be

needed to demonstrate that the member/participant is able to engage in FPS transactions. As the service provider, IPL have defined a multi-stage test program for members and participants to demonstrate their readiness for joining FPS. The later elements of this testing include ‘buddy testing’ where two or more members/participants will team up and send each other test transactions;
 Performance of the system is critical and must be

Control Systems
In addition to the local systems used to send or receive payments, there is need of a suite of control systems which log the local gateway onto the FPS system, send messages to the Switch (for example to change core central system parameters which are under the control of the member/participant), receive and process Unsolicited Status Messages (USMs) etc. It is necessary to ensure that all incoming messages are trapped, understood and acted upon where necessary. It is also necessary to be able to appropriately generate any out-going messages.

tested. It is envisaged that organizations joining FPS will need to both undertake testing of their local systems in isolation and also participate in integrated performance tests coordinated between IPL, APACS and the members and participants;
 Other non-functional testing, particularly resilience

Implications for Testing
The implementation of FPS will have wide implications on the testing required:
 The local solution to the implementation of FPS will

testing, should be undertaken. FPS is a 2/7 service and consequently organizations in the scheme are assumed to be available most of the time. Indeed some organizations (such as members and agencies) are mandated to be available to the system 2/7. Almost all of the above test stages will benefit greatly from the use of a test harness to simulate the Switch. IPL has provided a testing tool to use with FPS. This tool has a very rich functionality set and can be used in a number of different ways to support testing. Some of the more powerful implementations of the tool are technically complex and so a bespoke interface has been built to support the FPS project. In addition to this custom tool, other more common tools will be of value. This is particularly true for the performance elements of testing where the load is not necessarily being generated via the Switch but rather is being generated by customer-facing systems such as a website.

probably involve the development or enhancement of bespoke software, and so initial unit and system testing of code will be required;
 Internal integration and regression testing will be

needed to ensure that the new elements of the local systems can work with each other, can work with the gateway and have not negatively impacted any existing functionality;
 Business testing of end-to-end scenarios involving

Approach to Testing
AppLabs has extensive experience of large scale, business critical and customer-visible projects. In addition, AppLabs has specific experience of testing FPS from both the perspective of a member joining the scheme and of the Switch itself, as well as involvement in the scheme at a management group level. In our experience, good planning is essential in order to ensure that the coverage and prioritization of testing meets the needs of the business and reduces the inherent risks involved in making highimpact changes on IT systems.

payments, reversals, return payments and scheme return payments will need to be undertaken, checking the customer’s balance at all stages of the process;
 Negative testing of incoming messages will need to

be undertaken. Some elements of the data in each message are used by the Switch for routing, and as such are validated. Other elements are solely used by the receiving member and so the Switch cannot validate these. It will be necessary to negatively test these ‘payload’ elements of the messages;
App_WhitePaper_Faster_Payments_Service_1v03 Page  © 2007 AppLabs

Testing and integration is perhaps the most important part of the development cycle as it aims to assess the system’s suitability, stability, usability, and its ability to interact with other systems.

With a rich set of features, all defined in extensive functional and interface specification documents, plus challenging service levels to be met for both performance and availability, the implementation of FPS represents a technically demanding project. It must be finely controlled so that key functionality is already proven when external test slots become available for planned integration tests. With the modern media actively looking for problems in industries such as the financial sector, it also becomes ever more important to deliver the customer a service which is right first time. The next few years will be strenuous for finance organizations who, as well as implementing FPS and changes for the BASEL II Accord, will also potentially be faced with large-scale programs such as the Euro, SEPA and other regulatory changes. This is an ideal time for organizations to review the costs of software testing across the organization and to look at ways in which testing can become more standardized and more cost effective. Analysts estimate that testing, in a project like this, can be up to 70% of the total project cost. AppLabs’ advice to organizations is to ensure appropriate testing strategies and plans are in place to mitigate the inherent risk of changes to IT systems. Organizations must also ensure that their testing programs provide sufficient coverage and appropriate prioritization of tests and testing.

Understanding the Complexity of FPS
FPS is an extensive and complex system, which can result in significant time spent analyzing test requirements and also a vast number of potential tests which could be carried out. Through experience of FPS, AppLabs is able to quickly focus on the key challenges of the implementation, identify high value tests and deploy proven test techniques. AppLabs has developed a test pack which can be deployed quickly and effectively to assist organizations in their own testing of the system.

Test Management
As with good testing practice, managing the test process and testing against requirements will be essential in order to provide clear evidence of tests completed. The audit trail will need to satisfy requirements for the business itself, in order to be confident that changes will not adversely affect other areas of the business, and also for IPL compliance requirements to prove that the changes comply with the technical requirements of FPS.
App_WhitePaper_Faster_Payments_Service_1v03 Page  © 2007 AppLabs

Shared By:
Description: The Faster Payments Service was commissioned by APACS to enable balance transfers in near-real time. This White Paper looks at the impact this will have on IT systems and discusses the approach organizations must take to ensure successful participation in the scheme.