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.


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

• 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.

• 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.

• 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

• 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

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.

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.

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.

• 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

• IBM Financial Transaction Manager product page
  http://www.ibm.com/software/industry/financial-transaction-manager
• IBM Offering Information page (announcement letters and sales manuals):

http://www.ibm.com/common/ssi/index.wss?request_locale=en

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.