Payment Systems Survey 2004
Payments are undergoing tremendous upheaval these days. All over the world there is a growing awareness that it is no longer acceptable for infrastructure to restrain economic development. In Europe, severe cost cutting is a key issue due to European Commission regulations on fees for cross-border euro payments, with the objective to create a single European payment area (SEPA).
Banks often have internal processes and systems that have been in existence for 20 to 30 years. During this time numerous add-ons have been developed for process adaptations and product development. Now they are facing new external developments. They have to prepare for more efficient, low-cost processing and strong growth, particularly in cross-border traffic. Upgrading the old systems is often very costly, and maintenance costs are already too high in relation to current standards. So renewing remains the only option.
Domestic Payments:
The current status of domestic payments in the various countries differs enormously on the following parameters:
We see a trend towards shorter and more frequent clearing and settlement cycles, a more uniform processing based on speed and quality and an order and reporting (enriched) structure based on international (SWIFT) standards.
European Payments:
The new EU regulation puts heavy pressure on the banks to make their European cross-border processing more cost-efficient. In recent years, the Euro Banking Association has developed various initiatives such as the introduction of EURO1, STEP1 and STEP2. Domestic ACH operators are planning to develop competitive services such as Pan European Automated Clearing Houses (PEACH).
TARGET 2:
The TARGET system is currently under revision. After an extensive consultation round among all (potential) stakeholders, three central banks (French, German and Italian) are in the process of finalising the design of TARGET2 on behalf of the ECB.
It will be a “single shared platform”. Centralised liquidity management for large international banks is becoming a reality.
International Payments:
Payments processing is a volume business. Many small and medium sized banks will no longer be able to cover their costs. A large number of co-sourcing and outsourcing operations are expected in the years ahead.
Beside the specific developments in the geographical payment areas, there are some overall trends that will have a substantial impact on the payment business in the future.
Connectivity:
Connectivity is a key issue. There is a strong need for cheap harmonised solutions and leading operators in the market have accepted the challenge. Leading parties in the field are: SWIFT, with its SWIFTNet network services and standards, and product vendors such as Microsoft, with its cheap, highly standardised and flexible connectivity solutions based on the BizTalk product line; Sterling Commerce, with a global market share of approximately 50 per cent and IBM with its highly sophisticated Websphere (middleware) product line.
Standards:
In many countries, different formats and technologies are used for information exchange. The choice of the right technology and the right format can save substantial amounts of money,
Another aspect of standardisation is the processes in the various countries for domestic payments. Timelines and reporting vary dramatically. This prevents volume concentration and, consequently, cost reduction. This convergence from national to international standards is expected to receive more attention in the years ahead.
Customers’ Needs:
Large companies focus on the cost per transaction; not just on bank charges, but on the handling of payments including their own initiation and reconciliation process. Due to the lack of automatically processable remittance information, a manual reconciliation with their account receivables will easily cost them €20 per transaction.
Pressure is on the banks to develop capabilities to transfer extended remittance information, which is structured and based on international standards (XML). The cooperation of SWIFT, Rosettanet and the banks for STP process-able remittance information is already a step forward. This, combined with integration with ERP software, will lead to a substantial rise in STP rates and subsequently to cost efficiency.
Banks that are replacing their infrastructures usually do so with the objective of cost reduction. Cost reduction can be achieved by streamlining of processes, standardisation and concentration. Many banks concentrate their processing in a shared service centre or payment factory. This typically makes demands on the supporting infrastructure: multi-currency, multi-language, multi-label, etc. It also has an effect on a structure with separated front offices, for the distribution and the back offices, for the processing and connection to payment infrastructures.
A replacement of infrastructure contributes to the objective of cost reduction, although changes and streamlining of the process (and the organisation) have a bigger impact on costs and should be tackled with higher priority than the technical infrastructure.
Another high-level aspect is the technical environment of the system: is it merged with the choice of an integrated system for the bank or does it take place within a best of breed infrastructure orientation. Smaller institutions often have a preference for integrated systems. A well-chosen system provides all the necessary functionality, causes not too much trouble with interfacing and innovation, and is supported by the vendor. Large and sophisticated banks, however, opt for a best of breed infrastructure. Their demands are not covered by one system, so they have to choose specific software components for specific functionalities. A solid architectural basis is essential for these infrastructures. These infrastructures introduce the need for a middleware component. This is vital, since this reduces the interfacing issues to a minimum and guarantees flexibility in a complex environment.
These banks have often defined an overall architectural approach in which the usage and standards related to information exchange and middleware are already defined. The question is: does this fit with the package?
Other Requirements:
Flexibility in a package is important because it enables the organisation to respond to business and product changes. Beware, however, of excessive flexibility, as this can give rise to great complexity when the system is configured in order to match the business requirements.
Constant growth in the number of payment transactions makes scalability a knockout criterion. Indicators such as the number of customers or accounts, the number of transactions per month, peak volumes, etc. can help to give an idea of the practical scalability.
Capgemini’s system selection methodology has been applied at leading customers in the financial services industry around the world and minimises the risks involved in system selection.
System selection does not mean choosing a system with the most extensive functionality. There should be a match between the payment processes, the system and the organisation.
The most important selection criteria are
The system selection process must be driven from a business perspective.
A firm’s management buy-in to the project is a prerequisite. The start-up effort is to ensure that sufficient resources are available to the project. A clear plan with deadlines is in place and the members of the project team are aware of their responsibilities.
Business Vision:
The business vision based on strategy, value proposition, business processes, organisation and system philosophy provides the setting for the payment system. These fundamental choices are key for a successful selection and implementation project.
Requirement Specification:
In the requirement specification phase, the project team assembles and structures the requirements for its future payment system. The requirement specification is also used to prepare the request for information (RFI). This phase includes the initial selection of a possible system and vendor candidates, the so-called long list.
System Selection:
The objective of the system selection phase is to select the primary and secondary payment system. On completion of this phase, the organisation will know what the final choice of the system will be. This is achieved by analysing the results of the RFP, in-depth testing of candidate systems and performing workshops with the vendors.
Negotiation and Implementation Planning:
After the systems and vendors have been chosen, the ensuing negotiations are very important. The selected system is something the organisation will build its business on for a period of five to ten years. It is crucial that the agreement with the vendor reflects commitment from both parties. Implementation planning, also carried out in this phase, is part of the agreement.
Implementation:
Signing the contract is the beginning; implementation usually takes a significant length of time. The methods used to implement payment systems vary considerably. Capgemini has significant experience in implementing different payment systems. The time taken to implement a system is generally inversely proportional to the number of resources dedicated to the project.
For this Payment Systems Survey, Capgemini has examined systems of the 12 foremost vendors with regard to the key evaluation aspects of payments.
The results published in the report are based on the answers to an extensive request for information sent out to the participating vendors in October 2003.
The following vendors (in alphabetical order) participated in the survey:
| Vendor | Product name |
|---|---|
| Actis | ACTIS PABA/Q |
| Aleri | Atlas GBS |
| Aqua Global | Intercept |
| CBA | International Banking Automation System |
| CIBF | CI_ARC+ |
| Dovetail | Envoy |
| Financial Object | Activebank |
| Fundtech | Global PAY Plus |
| Intranet | Money Transfer System |
| R-Style | RS Payments |
| Temenos | Temenos T24 |
| TietoEnator | Global Solutions – Payments |
| TKS | Quartz |
The survey indicates that the selected payment systems generally cover most of the basic functionality required. The starting point was a high-level processing scheme. We drew a distinction between processing steps for the main process and processing steps for supporting processes. We asked the vendors whether and how the various steps in the process are supported. We also asked them if they had experienced situations in which one of the processing steps is replaced by another product.
The analysis of the functional requirements for each process step is just one part of the system selection process. This process scheme is fairly traditional; the functionality in the processes should cause no surprises, except perhaps for the routing, where there is a stronger emphasis on the requirements for the supporting process. Routing is the area where innovation and the effects of changing regulations have full impact. Increasing requirements related to anti-money laundering (AML) and fraud detection and automated exception handling and reporting also receive full attention.
The report provides the answers to establish a short list for your banks specific needs and requirements. In the report is, beside the earlier mentioned issues, attention paid to the following aspects:
The vendor and the product: Information about the company and their business and product strategy. Questions referred to the product, its installed base and implementation approach.
Generic features: Multi-currency, multi-language and user interfacing are discussed. Scalability and performance are reviewed, as well as security, authorisation and limits.
Functionality (products supported): What different kinds of payment products can be handled and routed by the system?
Functionality (main process): Routing and processing of the payment products, to what level can it be tailored and how are validation, identification and authentication established. Vendors provide information about reporting and clearing & settlement.
Functionality (supporting processes): Capabilities that the system supports besides processing the payment. Management information, tracking & tracing, exception handling, repair and fraud detection are measured in this category.
Technical and architectural aspects: Insight in the technical architecture of the solution, security capabilities and platform dependencies. The type of technology on which a system’s design is based, this information is significant for its future development possibilities as well as the capabilities to fit with an existing architecture.
Co-author: Maarten Meijer is senior consultant of Capgemini’s Payment Consulting Practise. He specialises in E-payment and M-payment channels. He is a member of Capgemini’s Mobile Payments group, which studies the power of the mobile channel.