IBM Financial Transaction Manager for SEPA Services

IBM Redbooks Solution Guide

Abstract

The Single Euro Payment Area (SEPA) involves the creation of a zone in which all electronic payments across Europe are considered domestic. There is no difference between national and intra-European cross border payments. SEPA aims to improve the efficiency of cross-border payments, to defragment national payment markets, and to allow customers to make cashless Euro payments by using a single bank account and payment instruments. SEPA consists of all 27 European Union (EU) member states and includes Iceland, Norway, Liechtenstein, Switzerland, and Monaco. The payment schemes and frameworks that are necessary to realize SEPA are defined by the European Payments Council (EPC).

IBM® Financial Transaction Manager for SEPA Services is used to manage, orchestrate, and monitor financial transactions that relate to SEPA payments.

Contents


The Single Euro Payment Area (SEPA) involves the creation of a zone in which all electronic payments across Europe are considered domestic. There is no difference between national and intra-European cross border payments. SEPA aims to improve the efficiency of cross-border payments, to defragment national payment markets, and to allow customers to make cashless euro payments by using a single bank account and payment instruments. SEPA consists of all 27 European Union (EU) member states and includes Iceland, Norway, Liechtenstein, Switzerland, and Monaco. The payment schemes and frameworks that are necessary to realize SEPA are defined by the European Payments Council (EPC).

IBM® Financial Transaction Manager for SEPA Services is used to manage, orchestrate, and monitor financial transactions that relate to SEPA payments (Figure 1).

Financial Transaction Manager for SEPA Services
Figure 1. Financial Transaction Manager for SEPA Services


Did you know?

The message formats that are adopted by SEPA are not limited to Europe. The SEPA message formats are based on ISO 20022, and ISO 20022 is also being adopted in China, Singapore, Australia, Egypt, South Africa and other countries worldwide. Significant opportunity is possible for reuse of IBM Financial Transaction Manager for SEPA Services.


Business value

Financial institutions are seeking ways to increase revenue opportunities by providing new services and increasing market share. They are also having to adhere to regulatory requirements for SEPA Credit Transfer (SCT). Many banks initially took a tactical approach for SEPA implementation and now have concerns that these platforms will not scale. These environments are typically complex and have the following characteristics:
  • Difficult and costly to maintain
  • Lack transactional visibility
  • Difficult to add new services
  • Slow to make regulatory changes
  • Duplication of services
  • Lack of control

The IBM Financial Transaction Manager for SEPA Service offering provides the following capabilities to address these issues:
  • Shorter path to new revenue

    Using industry standards facilitates integration with new and existing systems. Financial Transaction Manager uses pre-built SEPA integration maps.
  • Improved business agility

    Enable the ability to select the best product or service for any need. Selective outsourcing is enabled by using common interfaces. Application and integration testing are shortened.
  • Increased customer satisfaction

    Financial Transaction Manager provides a complete SEPA payments picture and more complete reporting for customers across a bank. Also, greater transparency on transaction status can be provided directly to customers.
  • Reduced operational risk

    Less complexity means a less fragile environment. Enhanced monitoring is provided across enterprise processing. There is also enhanced business activity monitoring.
  • Reduced cost

    There are fewer technical interfaces, business transaction types, and message types. Reusable tools support message types and business services. Immediate support is available for standard SEPA messages.


Solution overview

The adoption of SEPA introduces significant changes to users and processes:
  • International Bank Account Number (IBAN) and Business Identifier Code (BIC) replace national account numbers and sort codes.
  • The maximum execution time for SEPA credit transfers from electronic ordering to credit on the beneficiary account is one business day.
  • SEPA credit transfers are credited in full without deduction of fees from the principal amount.
  • Remittance information has a fix standard length of 140 characters, and banks are obliged to provide the full remittance information on account statements.
  • New optional data elements are added, including the following data elements:
    • Dedicated originator reference field (end-to-end reference)
    • Dedicated on-behalf-of fields
    • Purpose and category purpose codes
    • Non-urgent mass payments in euro
  • The SEPA XML format is binding for the exchange of payments between banks.
The deadline for changing to the new system for SCT is 1 February 2014. In Member States that are not using the euro as their currency, the deadline is 31 October 2016. Each country must ensure that the migration to the new SEPA instruments is conducted in accordance with the regulation. National timelines might be longer or shorter than at the general European level because some requirements and migration deadlines might vary from country to country during a transitional period. This transitional period will end on a date in 2016 or 2017, depending on the country, for all requirements.

The volume of transactions that are processed by using the SEPA scheme will increase significantly. Banks will need a robust and scalable platform to handle this increased traffic. IBM Financial Transaction Manager for SEPA Services supports SCT SEPA payment instruments.


Solution architecture

IBM Financial Transaction Manager for SEPA Services builds on the core functionality of Financial Transaction Manager. It is based on the core code base, database, and Operations and Administration Console (OAC) of Financial Transaction Manager. However, the entire Financial Transaction Manager Reference Architecture is not required. Financial Transaction Manager for SEPA Services also extends usage of IBM WebSphere® Message Broker, ensuring that XML messages arrive and are delivered by using WebSphere MQ queues.

Figure 2 illustrates the architecture for Financial Transaction Manager for SEPA Services.

Financial Transaction Manager for SEPA Services
Figure 2. Financial Transaction Manager for SEPA Services

Financial Transaction Manager for SEPA Services has the following core components:
  • Predefined message transformation from SEPA ISO 20022 formats into and out of the Financial Transaction Manager internal standard format
  • A reference implementation model that demonstrates interactions with the EBA STEP2 clearing and settlement mechanism

    This component includes bulking and sending payment files on their value date, receipts of verification files, receipt of daily reconciliation reports, receipt of incoming payments, and receipt of requests for recall.

  • Documentation for the SEPA implementation

Financial Transaction Manager for SEPA Services provides the following features:
  • Prebuilt message flows to manage SEPA-related interactions with a clearing and settlement mechanism
  • Ability to start, monitor, audit, and track SEPA payments
  • Transparency across SEPA processing
  • Increased ability to enable straight-through processing for SEPA payments
  • Robust and scalable environment to process large volumes of SEPA payments
  • Easier adoption of SEPA updates

Configuring Financial Transaction Manager for SEPA Services consists of the following steps:
  1. Install and configure IBM Financial Transaction Manager. Also, configure the Financial Transaction Manager database, Open Database Connectivity (ODBC) and Java Database Connectivity (JDBC) for IBM WebSphere Message Broker, and the OAC.
  2. Configure Financial Transaction Manager for SEPA Services with the default queue and load database definitions, and configure the IBM WebSphere Message Broker Toolkit.


Usage scenarios

This section describes two usage scenarios for SCT: the primary flow and the recall/return flow

Primary flow usage scenario

Figure 3 illustrates the primary flow usage scenario.

Primary flow usage scenario
Figure 3. Primary flow usage scenario

The primary flow usage scenario consists of the following steps:
  1. Credit transfer requests in the form of pacs.008 messages are introduced to the sending bank system when the originating bank places them onto Q1.
  2. Credit requests are accumulated by the sending bank until they are bulked into large Input Credit Files (ICFs) and sent to the STEP2 simulator.
  3. Each credit in the ICF is validated. The valid credits are settled by STEP2 and TARGET2 (simulated). The validation results are transmitted by the STEP2 simulator to the sending bank by using Q5 in a Credit Validation File (CVF).
  4. Each successfully settled pacs.008 message is packaged into a Settled Credit File and then sent to the receiving bank. The receiving bank unbulks the pacs.008 messages and places them onto Q4 for notification of the beneficiary bank.
  5. The sending bank uses the CVF from the STEP2 simulator to generate a set of pacs.002 responses, one per credit, that convey the success or failure of each credit request. These responses are placed onto Q9 for notification of the originating bank.
  6. Real STEP2 processing generates a Daily Reconciliation Report (DRR) for each sending and receiving bank. For simulation purposes, the STEP2 simulator is triggered by any message on Q6 to generate DRR files that contain settlement information for credit transfer bulks that are sent to and received from STEP2. DRRs are placed onto Q7 for further processing by the banks.

Recall/return flow usage scenario

Figure 4 shows the recall/return flow usage scenario.

Recall/return flow usage scenario
Figure 4. Recall/return flow usage scenario

The recall/return flow usage scenario consists of the following steps:
  1. Settled credits can be selected by using the OAC. A recall request can be issued from the sending bank. The OAC can be used only by the sending bank. Some form of external communication from the originating bank must be assumed as a trigger to the Sending Bank operator to initiate the recall.
  2. When bulking occurs at the originating bank, pending recall requests (camt.056) are bulked in an ICF message.
  3. STEP2 prepares SCFs (camt.056) and sends them to the receiving banks.
  4. The receiving bank receives the recall requests. The person who is responsible for them is alerted by the OAC to respond to the recall requests.
  5. Acceptance (pacs.004) or rejection (camt.029) of the requests drives the appropriate Settled Credit File (SCF) messages back to the sending bank.
  6. Recall request status at the sending bank is updated according to the acceptance or rejection.


Integration

IBM Financial Transaction Manager for SEPA Services can integrate with various partner systems, including client systems and file transfer solutions, such as IBM WebSphere Business Integration for Financial Networks.

Because Financial Transaction Manager for SEPA Services is built upon Financial Transaction Manager, it inherits the rich set of predefined interface protocols and formats that are delivered by Financial Transaction Manager and its WebSphere Message Broker infrastructure. These interfaces facilitate the integration of Financial Transaction Manager for SEPA Services functions with the following components (Figure 5):
  • The customer and the clearing channels
  • The bank’s core banking applications (such as customer management, account management, and arrangement conditions)
  • Specialized components such as fraud and exceptions

Integration with Financial Transaction Manager for SEPA Services
Figure 5. Integration with Financial Transaction Manager for SEPA Services


Supported platforms

For information, see "Detailed hardware and software requirements for IBM Financial Transaction Manager offerings" at:
http://www.ibm.com/support/docview.wss?uid=swg27027034


Ordering information

Table 1 shows the ordering information for IBM Financial Transaction Manager for SEPA Services.

Table 1. Ordering information
Program name: IBM Financial Transaction Manager V2.0 for z/OS®
Program PID: 5655-Y11
Entitlement identifierDescriptionLicense option/pricing metric
S0174TDIBM Financial Transaction Manager for SEPA Services for z/OS V2.0Basic OTC, per Install
S01708VIBM Financial Transaction Manager for z/OS® V2.0Basic OTC, per Value Units
Program name: IBM Financial Transaction Manager V2.0 for Multiplatform
Program PID: 5725-F79
Part numberPart description
E0F4GLLFTM for SEPA Services Per Install Annual SW S&S Rnwl
D0V55LLFTM for SEPA Services Per Install Lic + SW S&S 12 Mo
D0V56LLFTM for SEPA Services Per Install SW S&S Reinstate 12 Mon


Related information

For more information, see the following documents:

Special Notices

This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a client responsibility and depends upon the client's ability to evaluate and integrate them into the client's operational environment.

Profile

Publish Date
11 April 2013


Rating: Not yet rated


Author(s)

IBM Form Number
TIPS0993