The reality for many financial institutions is a transaction processing environment that has evolved through a combination of organic development and a merger or acquisition where case-by-case projects have driven point-to-point implementations. These environments have the following characteristics:

• Diverse transaction formats
• Varying processing rules and requirements
• Many-to-many connections
• Broad combinations of technology stacks and platforms

Equipped with these environments, financial institutions must track, manage, and report on transactions while facing the challenges of changing business requirements that demand rapid extension, expansion for additional capability, or both.

This IBM® Redbooks® Solution Guide describes how IBM Financial Transaction Manager V2 provides integration and orchestration of transactions with an architecture that enables a streamlined environment. Such an environment is easier to maintain; increases transaction visibility; facilitates reuse of services, data, and processes; and improves agility to respond to changing business requirements.

The reality for many financial institutions is a transaction processing environment that has evolved through a combination of organic development and a merger or acquisition where case-by-case projects have driven point-to-point implementations. These environments have the following characteristics:

• Diverse transaction formats
• Varying processing rules and requirements
• Many-to-many connections
• Broad combinations of technology stacks and platforms

With these environments, financial institutions must track, manage, and report on transactions while facing the challenges of changing business requirements that demand rapid extension, expansion for additional capability, or both. These environments resist change because they take on these attributes:

• Complex and costly to maintain
• Incompletely documented
• Duplicated services, data, processes, and functions
• Controlled by different organizations within the institution

IBM® Financial Transaction Manager V2 (Figure 1) provides integration and orchestration of transactions to enable an architecture with the following capabilities:

• Enables a streamlined environment that is easier to maintain
• Increases transaction visibility
• Facilitates reuse of services, data, and processes
• Improves agility to respond to changing business requirements

Figure 1. Transaction Environment Transformation
Did you know?

IBM is the largest vendor in the payments industry. IBM computers and systems process many of the payment systems around the world. IBM Financial Transaction Manager builds on IBM's payments expertise to help financial institutions increase revenue, reduce cost, mitigate operation risk, and improve regulatory and legal compliance. For more information, see IBM Banking Industry Framework: IBM Financial Transaction Manager speeds introduction of new transaction services at
ftp://ftp.software.ibm.com/common/ssi/ecm/en/bkb03012usen/BKB03012USEN.PDF


Business value

Virtually all financial institutions have multiple systems to process payment, trade, and securities messages. These systems have morphed over years or even decades and were implemented to be efficient at processing the needs of a particular department, function, or customer set. With so many systems evolving at differing times, paces, and purposes, process duplication inherently exists. Duplication and inconsistent processes create workflow friction, slowing client relationships and time to market. Because of this duplication, the existence of monolithic applications, redundant gateways, and numerous connections, payment systems can represent a higher percentage of expenses than they do revenue to a financial institution. The situation calls for strong pressure to reduce costs because increasing transactional volume might be unable to compensate for the revenue/cost differential.

While the internal pressures grow, financial institutions face increased pressure from nontraditional competitors who only offer niche products and services and lack the heritage that established financial institutions must maintain. Additionally, clients might exert pressure to have services added, modified to their own requirements, or to add new outlets that could never have been conceived during the original system implementation years or decades ago.

IBM Financial Transaction Manager provides an enterprise business-oriented view of payment and security messaging that can be modified and reused as needs change and competition morphs. Modeling facilitates the renovation and justifies each change along the way. IBM incorporates industry standards including ISO message formats and service-oriented architecture (SOA). The discipline and models of the Information Framework (IFW) provide tools, models, and techniques.

Implementing Financial Transaction Manager has the following typical benefits:

• Is agile in reaction to change
• Provides visibility of payments processes at design time and run time
• Integrates service components that are built, bought, or both
• Facilitates renovations by wiring together reusable service components
• Reduces the cost and impact of change
• Reduces the cost of testing additional applications with external networks
• Enhances liquidity management monitoring and control
• Reduces cost by enabling payment efficiencies and reducing system duplication
• Improves customer satisfaction with faster time to market

Solution overview

IBM Financial Transaction Manager provides the basis for defining and further customizing a bank’s financial messages handling platform (see Figure 2).


Figure 2. Payments handling financial messaging platform

These platforms typically handle payments processes, but are also used for other types of financial messages such as securities message handling. A financial messages handling platform that is specialized for payments covers the entire payments handling process of a bank, from reception of payment orders through the payments factory to delivery of the payment orders to the corresponding payment partners. It covers the reception of payments requests from payments partners through a payments factory. It also covers the delivery of an execution report or statement to the bank’s part of the payments handling process. These processes include the processes of the following hubs:

• The enterprise hub (processes oriented toward corporate customers)
• The compensation hub (processes oriented toward correspondent banks and the clearing and settlement mechanisms)

Financial Transaction Manager delivers a framework of the components that are required to set up a bank’s payments or financial messages handling platform step by step. It starts with a limited scope in terms of payment types and processes and continuously enriches it, adding new functions and processes to it. These components cover several functions that are outlined in the following section.

Immediately usable functions

The following functions can be used immediately:

• The administration and configuration user interface, which provides alerts raising, payments monitoring, and administration of the major parameters such as channels, formats, and calendars
• The transaction database, which is designed for high performance and audit trailing
• The internal standard format, which is required for handling and monitoring different types of payment messages while using a single reporting and monitoring mechanism
• The business dashboard infrastructure and dashboard examples
• A sample payments handling application for verification of the installation and that delivers the basis for customization
• Prebuilt message transformations

Customizable functions

The following functions are customizable:

• Transaction routing services
• Transaction storing services
• Events and process orchestration services that you can define by using state machine diagrams

This task is simplified by using the supplied IBM Rational® models.

• Client acknowledgement services, which can be customized to meet specific payments partner or tool requirements
• Message mapping services, which facilitate the mapping between internal formats and the specific customer formats and interfaces
• Bulking and debulking services, which are delivered as examples that can be adapted to fit specific requirements
• Alert management and transaction status services, which can be raised when events or payment object statuses are reached
• Request/response correlation services, which facilitate the mapping of outgoing and incoming messages or interfaces

Middleware infrastructure

The required middleware infrastructure is delivered as part of the Financial Transaction Manager product download. Financial Transaction Manager has been thoroughly tested on the underlying middleware infrastructure.

Figure 3 shows the Financial Transaction Manager components.


Figure 3. Financial Transaction Manager components


Solution architecture

The Financial Transaction Manager platform consists of several components that are deployed and manifest in a Financial Transaction Manager solution:

• Data Model
  

The data model includes an operational database and a configuration database that are deployed in IBM DB2®.

• IBM WebSphere® Message Broker artifacts
  

Message flows to facilitate runtime message processing are provided for deployment in IBM WebSphere Message Broker.

• Console
  

An operations and administration user interface is provided for deployment in IBM WebSphere Application Server.

• IBM Rational Software Architect plug-ins
  

A set of model state machines and support for creating custom state machines are deployed in Rational Software Architect.

• Sample dashboard and application
  

A sample application is provided for deployment in Rational Software Architect and WebSphere Message Broker. Also a sample dashboard definition is provided for deployment in WebSphere Business Monitor.

Figure 4 illustrates the typical interaction between the components of a Financial Transaction Manager solution.


Figure 4. Financial Transaction Manager component interactions

WebSphere Message Broker Toolkit and Rational Software Architect are used to define and implement the desired transaction flows. These flows are deployed to the Financial Transaction Manager transaction engine in WebSphere Message Broker and to the data model in DB2. The operations and administration user interface dynamically adapts to these flows and provides user interaction for configuration and visibility to transactions for monitoring and management.


Usage scenarios

Multiple solutions have been implemented and running in production status for some time or have been implemented as part of proof-of-concept interventions as indicated by the following examples.

Enterprise platform

A European banking customer wanted to be able to receive different types of payment orders from their enterprise customers, through different available channels. By implementing an enterprise platform, this bank used Financial Transaction Manager to handle the payment file and order acceptance processing. The solution included the following features:

• File reception and registration in the Financial Transaction Manager database (audit trailing)
• Validation that customers are authorized to use the service and the conditions that govern the service
• Detection of the file format (SEPA or domestic), corresponding debulking of the file into remittances and orders, and their registration in the audit trail
• Remittance and order validation toward customer data
• Order routing to the corresponding payment factory
• Delivery of acknowledgments to the customer (such as file reception, file acceptance or refusal, and order delivery to factory)
• Delivery of payment execution feedback, in addition to returns and refusals or statements to the customer’s preferred channel

Figure 5 shows the function model of an enterprise platform.


Figure 5. Enterprise platform

Compensation hubs

Banks all over the world have implemented compensation hubs based on Financial Transaction Manager. These platforms receive orders for payment that a bank places into an account. The bank must send these payment orders for processing to the bank of the receiver of the payment. The routing of the orders to the partner bank follows routing rules that are specific for each bank. Through their payments processes, these banks receive the payment orders from the back-office systems or payment factories of the bank. They do a format validation and transformation of these orders. They also record the orders in the audit trail database. At the maturity date, the payments orders are extracted from the database and routed to the best fitting execution partner. The partner is determined through an order routing mechanism, based on reachability, efficiency, cost and other criteria. Before transmitting the orders to the corresponding gateway, they are transformed to the partner’s format (such as XML, ISO 20022, and flat file) and bulked according to the partner's requirements.

Often the compensation hub requests a delivery acknowledgment from the gateway. The acknowledgement is then recorded in the audit trail and states that the payment order has reached the counter party bank or partner. This platform also receives payments messages. The messages are recorded. If required, the messages are mapped to a former outgoing payment message to which they respond and are then handled through customized processes.

Figure 6 shows the function model of a compensation hub.


Figure 6. Conceptual compensation hub that can be built by using Financial Transaction Manager as the hub

Funds routing platform

A funds routing platform is another type of platform that is based on Financial Transaction Manager. This platform receives nonpayments-based financial messages from different actors and delivers these messages to the correct destination for execution or custody.

This platform as the following layers:

• The Access layer includes the interfaces the different users and channels will use to access the platform.
• The Protocols and Gateways layer takes care of message reception and delivery.
• The Function layer provides the required business services.
• The Application layer delivers the customizable bases of these services.
• The Data layer includes the Financial Transaction Manager delivered data and the funds hub.
• The Infrastructure layer can be implemented for high availability or as a virtualized cluster.

Figure 7 illustrates the layers of this platform.


Figure 7. Funds routing platform


Integration

In considering the adoption of new applications, you must consider several important facts, such as the ease that the application integration allows for a gradual renovation of your business functions environment with your previous investments. You must ensure that it provides full integration with existing and core banking applications (such as antimoney laundering, risk, fraud, and accounting) and most enterprise resource planning (ERP) systems, just as Financial Transaction Manager does.

Financial Transaction Manager is a software package used for the implementation of an integration layer to manage, orchestrate, and monitor financial transactions. It provides integration through a common data and message model, based on an industry standard (ISO 20022). Financial Transaction Manager has a strong alignment with major industry standards (such as SWIFT (MT, MX), ISO 20022, and EDI) and uses these standards to facilitate integration with new and existing systems. It is an integration platform that uses de facto leading IBM middleware components. Adoption of Financial Transaction Manager integrates to, and shields internal applications from, external standards changes. It provides the common integration capabilities that are needed for managing financial transactions. Customers can use Financial Transaction Manager to facilitate back-office integration and track transaction status.

Financial Transaction Manager uses a unified development methodology and environment for middleware integration. Repeatable patterns or models (proven, reusable assets) are integrated in Financial Transaction Manager. For example, the Router and Message Correlator patterns are inherited from the core component WebSphere Message Broker and are widely used.

Financial Transaction Manager has built-in integration with the market leading business rules management system IBM Operational Decision Manager. Therefore, the complex rules that relate to the enterprise can be externalized yet used by the transaction flow to build dynamic internal decision points.


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.

Table 1. Ordering information

Program number	Program name
5725-F79	IBM Financial Transaction Manager for Multiplatforms V2.0
5655-Y11	IBM Financial Transaction Manager for z/OS® V2.0

Related information

For more information, see the following documents:

• 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, and click Search. On the next page, narrow your search results by information type, geography, language, or all three options.