Single Euro Payments Area

TheSingle Euro Payments Area (SEPA) is a payment-integration initiative of the European Union for simplification of bank transfers. As of March 2012, SEPA consists of the 27 EU member states, the four members of the EFTA (Iceland,Liechtenstein,NorwayandSwitzerland) andMonaco.

The projects aim is to improve the efficiency of cross-border payments and turn the fragmented national markets for europayments into a single domestic one. SEPA will enable customers to make cashless euro payments to anyone located anywhere in the area, using a single bank account and a single set of payment instruments.

The project includes the development of common financial instruments, standards, procedures, and infrastructure to enableeconomies of scale. This should, in turn, reduce the overall cost to the European economy of moving capital around the region (estimated as two to three percent of total GDP).

The main objectives of SEPA are Standardization of euro payments: equal time limits, equal fraud-risk levels, equal processes, all-electronic straight-through processing, no difference between national and international payments in the SEPA area; strengthening trust and reliability on a pan-European basis.

SEPA Direct Debits are designed to replace national Euro Direct Debits (in the longer run) as well as to deliver the cross border Euro direct debit functionality.

Background

Our client, a global diversified financial services company, with major operations in Europe, wanted to be one of the first institutions to offer SEPA Direct Debit solution in the market.

The proposed solution would support the SEPA Direct Debits capability for incoming Direct Debits with the Core RuleBook 4.0 and B2B RuleBook 4.0 specifications. This will provide our client to become a market leader in the provision of SEPA Direct Debits as the market matures. The solution would follow a typical Automated Clearing House (ACH) payment life cycle and provide the government beneficiaries quick remittances.

Our client had been offering the Creditor and Debtor functionality for a long time. However according to the new rules to comply with SEPA Direct Debit requirements, the proposed solution must adapt to the changes introduced as part of Rulebook version and ISO XML upgrades.

The proposed solution should incorporate the validation functionality for both incoming and outgoing transfers. Generic Validations for Incoming Collections (Client as Debtor Bank), include

Incoming File Validations Transaction-Level Validations Mandate lodgment and Validation Rejects Processing Returns Processing Cancellation Receipt Processing Reversal Receipt Processing Authorized Refunds Processing Unauthorized refunds Processing.

The Overall Solution

Solution Challenges

Generic Validations for Outgoing Collections (Client as Creditor Bank), include

Incoming File Validations Transaction-Level Validations Mandate lodgment and Validation Rejects back to customers Message Generation to EBA Cancellation Processing Reversal Processing Reject Receipt Processing Return Receipt Processing Refunds Processing

The proposed solution must continue to support all processes outlined above with upgrade of Rulebook versions and ISO XML messages and any future changes in the Rulebook specifications by EBA.

As with our other projects with our client, Xoriant entered the scenario at this stage because of our proven experience in deploying payment solutions and our technological capability. Our client also saw Xoriants track record of successfully delivering high class software applications with multiple (including new) technologies, especially a comprehensive payment gateway for our clients own use, and had provided significant domain knowledge and technology depth to deliver a massively scalable payment processing platform. This track record, in addition to the combination of customer intimacy, geographic reach and cost-effectiveness offered by Xoriants global delivery model, influenced our client to award this project to Xoriant.

Our Solution

After detailed discussions with our clients business and technical teams, our team decided to reuse the highly scalable, reliable and available payment platform that we had already built for our BACS project and built a functional module on the platform to offer SEPA DD functionality, while using the functionality of the platform.

Systems Architecture Diagram

MailChannel

TelephonyChannel

Customer (Credit)Risk

Systems

ElectronicChannels

BranchChannel

FXEngine

Core BankingEngine

MI

Customer(Fraud)

Risk Systems

PaymentEngine

CSM1 CSM2

DD CLaims Architecture

Scope of Banks own systems

Functional Details

It was decided that the client specific high volume, low value payment platform, as mentioned above would provide low value payment processing for several clearing services, including ACH (Automated Clearing House - prevalent principally in the US), SEPA (prevalent in the UK), and SEPA (Single Euro Payment Area - being implemented in the European Union common currency countries).

For the SEPA DD system, this common payment platform would provide the following common functions: - Bookkeeping - Mandate verification and creation - Account Validations - Sanctions screening

The following functions would be handled by the SEPA specific module which would sit on top of the platform: - Handling bulk level payment processing and Individual Payment processing - Support different workflows: Pass-through where the payments go through part of the workflow. Manual where the payments received are first verified by Operational Users before they could be automatically processed in the system Full processing - RBCS Check Credit Check before initiating account entries. - Send and Receive Acks/NAcks from EBA and send them to customers. - Process the returns and rejects based on the payment processing service level agreements adhering to ACH payment life cycle.

SEPA DD payments module handles customer bookings in one payment leg and works with multiple partners for final disbursement, while interfacing with Global Interdict, Statement Enrichment System, Anti Money Laundering system, Credit Check Systems, Book Keeping Systems, etc.

Technology Details

Modular approach was adopted in the solution to allow the business and operations users to configure the modules with the use of graphical user interface to define the processing workflows.

The common payment platform was architected to yield high volume transaction clearing as well as highly scalable, secure and available technology infrastructure.

The platform was primarily developed using Java, J2ee, Hibernate, Weblogic, and Oracle database. We seamlessly integrated the front-end that was also developed using the client-approved GWT framework.

Performance and Throughput

In addition to the functionality, the new platform and the SEPA module were also supposed to allow much higher throughput than what was currently experienced. The initial requirement for throughput was 150,000 to 230,000 transactions per day, which is likely to increase to 1,000,000 transactions per day as the business conditions improved and more customer branches came online.

To obtain higher throughput, key focus and attention was given to complex and time consuming processes across various components and aspects of the system. First we isolated the components that were responsible to validate the payments file, before persisting them to the database.

The implementation used multiple protocols like JavaFal, NDM and IBM MQ to exchange payment files between partners. The technical components were designed using standard Java Enterprise technology comprising of Transaction Based Management, Stateless Container Managed Beans, Message Driven Beans, and Core Java. Annotations were used to inject resources and to decide the behavior of the beans to provide flexibility and dynamic processing, rather than relying on configurations files and bean definitions files.

iPlanet SunOne server was used as a Webserver for URL redirection towards Weblogic Web container (also known as a Servlet container) to interact with Java servlets. The URL redirection helped to internally authenticate the user credentials in the background from the clients internal authentication service before user could start using the application front end to provide security, concurrency, lifecycle management, transaction, deployment, and other services.

We used multithreading in our architecture to allow the processor switch between different threads. This context switching was planned frequently enough that the user perceives the threads or tasks as running at the same time.

The SEPA DD specific module was also implemented using the same technology parameters and design methodologies, while leveraging the API and services offered by the common payment platform.

User Interface

The web application for the SEPA system was critical for the clients Operation team to review the payment processing, extract reports, identify payments that are marked for review and administration of users role and usage permissions of web application. There were real time dashboards that show up on user login to render information pertaining to his/her role. Here background pull/push technology was used to enable user a click-free intervention in order to see the real time payment processing status. All this was enabled using state-of-the-art graphical user interface fully implemented using the Google Web Toolkit (GWT) technology. GWT renders code on server side and then pushes to the browser, thus providing abstraction from the markup/script language commonly used for web frontend development effort. GWT is more of a programmers language compared to HTML based web design/development encapsulating the technicalities around HTML tags. GWT development is compatible across multiple browsers and hence does not require creating frontend that is tightly coupled with the web browser client on users machine.

These operations were atomic in nature and every payment was validated within a single transaction. This was done to meet one of the requirements to reject the file if even a single payment has any validation problem. Since the solution was more of a middleware similar optimization was required in the output data file generation. We implemented custom cache for the static data, so that the database access is minimized, controlling the frequency and number of parallel threads could be spawned within the application to control the memory and CPU usage. A mix of Hibernate queries and native queries was used to maintain applications balance around database communication and to optimize the resultant performance impact.

System Integration Testing

For our test strategy, our QA leader was involved right from the functional requirement phase and technical design for inputs that helped our development team to plan and schedule the system integration testing phase to be carried out in three phases. The first phase mainly focussed on the pass through and manual workflows. The second phase focussed on the full processing flow. The third and final phase was about the Debit and Credit role flow. The third being the final phase also included regression and end to end testing with channel partners.

Our QA team was responsible to obtain a sign-off on the test plan from the business analysts and the development leads, thus ensuring comprehensive coverage of test cases around functional points during the development phase.

Our test strategy was a mix of manual and automated testing depending on the use cases and implementation. A dual approach was preferred to utilize best of both approaches.

Unit tests conducted by developers using JUnit before submitting code for reviews and submitting to code repository Development Integration Testing executed by developers on their own code before handing over the application to the testers System Integration Testing phase wise testing to ensure that the key functional areas are tested earlier. SIT comprises overall functional testing involving positive and negative test cases, integration testing with payment partners one by one with their individual SIT environments. End to End testing of the flows.

The SEPA DD module went through functional testing along similar lines.After the platform and functional modules were integrated, the combined environment went through the following tests:

Testing

Testing was divided into (1) Platform testing and (2) Module testing.The platform went through following tests:

Performance Testing

Xoriants performance testing team for testing this application was a mix of developers and test engineers focused mainly on the performance aspects of the application. The performance testing was done on the combination of the platform and SEPA DD functional module.

Performance testing had an independent environment, where the system architecture was production like in terms of memory, CPU, and database, each fine-tuned with production like parameters to simulate production like environment for performance testing.

All performance testing was fully automated from staging the data for each and every test case, execution, tracking results and generating reports. The statistics of each performance were recorded automatically in log files.

Performance testing generated the following reports Volume processed per hour Peak memory utilization Peak CPU utilization Number of threads used during peak operations Number of database commits. Time taken to process transactions Time taken to generate processing outputs Time taken for end-to-end flows (each flow tracked individually)

Using this platform-module approach, we were able to achieve richer functionality, higher throughput, a better user interface and higher connectivity than what was available before. We achieved a ten-fold increase in performance using this approach, by achieving performance optimization in each individual component of the system. Now our team is involved in building next versions of SEPA, enhancing the platform functionality and building new modules for other payment systems.

Results

Our client was one of the first banks to offer SEPA DD functionality to its European and global clients. This was done by offering a modular, secure, highly scalable and functional system with great expansion capabilities.