Java Payments Network: A New Era for Payments Technology

With institutional input from Voca (previously known as BACS), Barclays and Wachovia, the founding JPN members of Cambista, Computacenter, Concise Group and Sun Microsystems have been recently joined by C24 Solutions and Generated Systems Technologies.

The JPN brings together the expertise of technology vendors, systems integrators and consulting companies specialising in the provision of payments solutions to financial institutions, industry service providers and large corporates. The participating companies share a realisation that technology has often become a hindrance rather than an enabler for the payments industry, and that technology should be more addressed to particular business challenges – not just individual projects, but industry-wide, long-term trends.

The stated aims of the JPN are:

• to develop Java-based payment systems for the financial services industry through the active collaboration of the members;
• to share information and technology developments between members to improve interoperability, performance and reliability and thereby reduce project cost and risk for institutions; and
• to provide a forum, through regular meetings, events and other communication channels, for institutional customer input with the aim of improving the functional fit of payments product development.

Attacking Cost and Complexity

Most banks want to improve service innovation, liquidity management and regulatory compliance. But they are often hampered by a payments infrastructure which poses a range of problems, including:

• duplication of efforts required to meet new regulations, or deal with new initiatives and standards development;
• duplication of manual processing efforts, such as repair, contingency and customer support;
• duplication of validation and processing such as field validation, reference data validation, liquidity management, and fraud detection;
• high cost of maintenance;
• no provision of centralised management information for processing, such as liquidity management or fraud detection;
• lack of consistency of service to customers who span business units;
• difficulty in providing an integrated payment offering to customers, especially corporate companies with cross border and domestic requirements;
• difficulty in offering institutional customers a white label service; and
• difficulty and sometimes lack of ability to support predicted growth in electronic payments.

Banks are aware of their problems with complex, legacy payment systems. They are also aware of the need to address the issue now in order to be in good shape to tackle future challenges, including:

• increasing demand from regulators and large customers to ensure secure contingency planning for key payment processes;
• making changes to all systems affected by new regulations or messaging standards;
• reducing cost per transaction will remain key as revenue per transaction is likely to decline while volumes grow;
• pressure to reduce execution times and fees applied to domestic and cross border payments;
• threat to profitability as the size of float available for investment is under pressure from reduced clearing cycles; and
• the need to add value and differentiation to a product that can now be described as a commodity.

Single Generic Payments Architecture

To address these issues, the JPN promotes the use of a single generic payments architecture that provides control and functionality for all payment types within the organisation. It sits at the heart of all the bank’s payment operations, reducing the duplication of functions in the back-office and providing generic payments capabilities that can be used by any other system in the bank.

The JPN architecture makes use of the processing power of existing back-office systems, but separates out the duplicated functionality. This is migrated to the generic mid-tier layer, which sits above and coordinates all back-office processing. Banks can take a payment instruction and data in a generic way, and then business rules are used to ensure the right systems are accessed to process that payment further.

The JPN architecture is abstracted from:

• delivery channel, both customer and to the bank’s back-office infrastructure;
• payment type, via individual processing maps;
• format, both inbound and outbound, all payments are transformed into a consistent representation;
• bank-specific processing and rules;
• third-party components such as FX applications, correspondent banking, liquidity management, or fraud detection; and
• reference data sources.

Through the use of processing maps, the JPN architecture is capable of supporting multiple formats, settlement networks and delivery channels as well as online messaging and batch files. It focuses on common processing and abstracts the differences.

Customisation and Flexibility

JPN members understand the need to tailor architecture especially for each bank’s needs. This can involve a new mid-tier layer that sits on top of existing architecture and systems. It will also involve the use of packaged solutions that provide large, fast-to-deploy and customisable building blocks, or the use of lower level components to meet a bank’s specific needs. In either case, JPN members will work with the bank to develop business rules and processing maps to deal with all the required payment types and services. This will almost always involve integration to third party products.

Specific Functionality

The JPN has developed a range of solutions and services to leverage the generic payments architecture; these include functionality for SWIFTNet testing and migration, cash management, wholesale payments, balance and transaction reporting, as well as sweeping and pooling.

The Java Payments Network realises that the challenges organisations face come from two sides – top-down, business-driven challenges and bottom-up technology-driven challenges. Working together, members of the network can help banks address both in a cohesive manner.