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.
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).
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.
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.
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 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.
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.
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:
- 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.
- Configure Financial Transaction Manager for SEPA Services with the default queue and load database definitions, and configure the IBM WebSphere Message Broker Toolkit.
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.
Figure 3. Primary flow usage scenario
The primary flow usage scenario consists of the following steps:
- 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.
- Credit requests are accumulated by the sending bank until they are bulked into large Input Credit Files (ICFs) and sent to the STEP2 simulator.
- 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).
- 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.
- 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.
- 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.
Figure 4. Recall/return flow usage scenario
The recall/return flow usage scenario consists of the following steps:
- 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.
- When bulking occurs at the originating bank, pending recall requests (camt.056) are bulked in an ICF message.
- STEP2 prepares SCFs (camt.056) and sends them to the receiving banks.
- 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.
- Acceptance (pacs.004) or rejection (camt.029) of the requests drives the appropriate Settled Credit File (SCF) messages back to the sending bank.
- Recall request status at the sending bank is updated according to the acceptance or rejection.
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
Figure 5. Integration with Financial Transaction Manager for SEPA Services
For information, see "Detailed hardware and software requirements for IBM Financial Transaction Manager offerings" at:
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 identifier||Description||License option/pricing metric|
|S0174TD||IBM Financial Transaction Manager for SEPA Services for z/OS V2.0||Basic OTC, per Install|
|S01708V||IBM Financial Transaction Manager for z/OS® V2.0||Basic OTC, per Value Units|
|Program name: IBM Financial Transaction Manager V2.0 for Multiplatform|
Program PID: 5725-F79
|Part number||Part description|
|E0F4GLL||FTM for SEPA Services Per Install Annual SW S&S Rnwl|
|D0V55LL||FTM for SEPA Services Per Install Lic + SW S&S 12 Mo|
|D0V56LL||FTM for SEPA Services Per Install SW S&S Reinstate 12 Mon|
For more information, see the following documents:
- IBM Financial Transaction Manager product page
- IBM Offering Information page (announcement letters and sales manuals):
On this page, enter Financial Transaction Manager for SEPA Services, select the information type, and then click Search. On the next page, narrow your search results by geography and language.
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.