e-Business Standards Implementation in Financial Industry

Roy Abraham

1) Introduction: Business-to-Business (B2B) integration refers to electronic commerce business model in which business information is exchanged between business enterprises or trading partners.B2B integration is not a new concept. It has been with us for a long time. First, it appeared in the horizon in the form of EDI (Electronic Data Interchange). With the advent of internet, Java and XML (eXtensible Markup Language) based B2B integration is evolving and undergoing a completely different outlook. The following is the list of advantages of B2B integration.
• Reduce human intervention and automate the trading partner business transaction,
• Reduce cost and increase productivity,
• Reduce transaction life cycle,
• Increase the security of the transaction,
• Better data accuracy and integrity,
• Better monitoring,
• Less subjective and human errors,
• Better reusability and portability.

As described in the previous section, B2Bi rarely stands alone. In many cases B2Bi is implemented in conjunction with other technologies such as BPM (Business Process Management) architecture and STP (Straight Through Processing)

2) B2B integration and Business Process Management (BPM) Architecture

Business Process Management deals with defining, analyzing, managing and implementing the interaction among internal systems, people and external trading partners. In traditional systems, Business Logic (objective part) and Business Rules (subjective part) in a Business Process are tightly coupled. Hence, any requirements change in either one results redesign or re-factoring (depends on the extent of the change) of business process. However, laws, rules and regulations of certain business process change constantly. This necessitates the decoupling or loose coupling of Business Rules and Business Logic. Business Logic is hard coded (means, business logic change depends only on requirement change). On the other hand, transient changes in rules, laws and regulations are encapsulated in Business Rules. These Business Rules may or may not need human intervention. Business Logics are implemented in Application server (for example, an EJB or IoC container). Business Rules, which need human intervention is implemented in Workflow server. Business Rules, which do not need human intervention is implemented in Rules Engine.

A typical example is the life cycle of a tax return in IRS (Internal Revenue Service). Rules and laws continuously change as new legislation come into effect every year. However, it is extremely difficult to change or re-factor the existing applications which process the tax returns as per every change in the tax law. The best strategy is to separate business logic and business rules from the business process. The subjective and transient tax features are encapsulated in business rules. The objective and permanent tax features are encapsulated in business logic. Whenever a tax law changes, the business manager create a business rule associated with the new tax law and store in a rules engine. When the system receives a tax return, application server applies business logic and rules engine applies business rules on tax return data. If the outcome of this processing triggers an audit, tax return is sent to a workflow for appropriate human intervention. Such a BPM architecture using an Application server environment, Workflow server and a Rules engine environment is shown below.

Figure 1 BPM logical architecture

BPM provides a holistic approach to Software development involving technology (objective) and human behavior (subjective). The important elements which constitute BPM are described below.

a) Business Logic: Defines the objective behavior of permanent nature. In software terms, this attribute never changes unless and until requirement changes. This also implies that there is nothing absolutely permanent in software development. The core business model of the enterprise is captured in the business logic.
b) Business Rules: Defines the objective behavior of transient nature. However, this attribute changes within the confines of the requirements. This encapsulates the forces outside the enterprise which influence the core business model such as market forces and government policies. The daily or weekly promotion sale of the company or changing the sales tax structure due to government policies are few such examples.
c) Work flow: Defines the subjective behavior of transient nature. This is where the human aspect interacts with the core business model. For example, a customer agent partially forgives the overdue penalty of a customer and her supervisor completely forgives it due to good payment record of the customer.
d) Trading Partner Interaction: Defines the business relationship with other enterprises. In the current integrated business environment, business to business transaction is inevitable in one way or other.
e) Enterprise Integration: Defines the integration of various software and data assets within the enterprise. It can be legacy assets accrued over the years such as main frame or software written in C language.
f) Life cycle management: Almost every business model has to perform a sequence of tasks from inception to fulfillment to complete the business process. It can be a claim processing, an order fulfillment of a shopping cart or a loan processing etc. BPM provides the state management of individual steps involved in the Business Process.


Figure 2: Elements of BPM

g) Monitoring: The entire software development project is business requirement driven. The business requirement is stake holder driven. Hence, directly or indirectly the business manager is the ultimate stake holder of the software development. However, the business manager may not have the technical acumen to understand the complexities of the software process. She has to believe what she is told by the development team. This poses considerable challenge to the Business Manager on day to day operations of Business Process. The monitoring tools of BPM provide such a visibility to the business process. Monitoring may include but not limited to Business Activity Monitoring (BAM) of Key Performance Indicators(KPI), Six-Sigma, compliance monitoring (like SOX) etc.

3) B2B integration and Straight Through Processing (STP)Straight Through Processing allows end to end information movement through trading partners without human intervention. STP is analogous to Supply Chain Management (SCM) in the manufacturing industry. STP has it origin in the trade life cycle from initiation to settlement in capital markets and payment transactions. Lately, STP concept is embraced by other financial sectors such as banking and mortgage industry. STP is very closely related to BPM described before. How STP, BPM and SCM are related is described below using an example.

A weather forecasting company informs a building equipment retailer that there would not be any snow in Virginia until third week of January and may not store snow shovels in Virginia, but stock pile in Kentucky and Colorado. The retailer sends this information to snow shovel manufacturer and others in the supply chain. A trucking company which already sent a truck load of shovels to Virginia can re-route to Kentucky or Colorado. With the introduction of RFID (Radio Frequency Identification), the efficiency of SCM reached the consumer level. This way Supply Chain Management (SCM) tools efficiently manage inventory. Using RFID, a SCM tool can monitor the movement of a digital camera from the manufacturer to wholesaler to retailer until it is delivered to the customer.

What is SCM to manufacturing industry is what STP to financial industry. Once a business data is created by an Originator, it may pass through a number of organizations until it is delivered to a consumer. Such a business document requires a unique id (similar to RFID) so that STP tools can monitor it. Life cycle of a mortgage is typical example of utilizing STP. For example, when a lender originates a loan, the subsequent mortgage pass through different trading partners such as secondary market, vendors, service providers, custodians, warehouse lenders, servicers and investors using B2B transaction. Thus STP provides life cycle management of a business document spanning multiple trading partners. Usually, the unique id used in mortgage document is Mortgage Identification Number (MIN). In the tax return example described previously, may use social security number as the unique id. Using this id, disparate enterprises can monitor and process the tax return end to end. Currently, eBusiness standards such as FIX and SWIFTNet provide STP based services.

4) FIX
The Financial Information Exchange (FIX) is a message standard intended for use between trading partners to facilitate the electronic exchange of information related to securities transaction. An important feature FIX provides is the Straight Through Processing (STP) solutions. This is accomplished by streamlining message life cycle processing through confirmation, settlement and reconciliation. FIX specification is independent of any particular communication protocol, security protocol or network model. The FIX protocol is defined in two levels: session level protocol and application level protocol. The session level protocol deals with the delivery of data. On the other hand, the application level protocol deals with the business related data content. In traditional FIX implementation, a FIX engine manages the session protocol layers and application protocol layers. The FIX engine is responsible for managing the FIX message exchange among the trading partners.

When he FIX engine of a trading partner A (acts as client) connects to the FIX engine of a trading partner B (acts as server) and a FIX session is established. A FIX session is defined as a bi-directional stream of ordered messages between these two trading partners. A FIX session consists of three parts, Logon, Message Exchange and Logout. The Logon is responsible for the creation and maintenance of the telecommunication link, authentication of the client by the server and initialization of the message. After successful logon, actual messages are exchanged. The messages can be administrative messages or application messages. The administrative messages deals with the utility features of the protocol such as heartbeat, test request, resend request, sequence reset etc. The application messages contain business related messages such as quote request, quote cancel, quote status request etc. After completing normal message exchange, the session is terminated with the exchange of Logout messages.

The FIX messages (both application and administrative) consist of a standard header, message body fields and terminated with a standard trailer. The header defines mostly meta-data about the message such as message type, length, destination, sequence number, origination point and time. The standard trailer consists of signature information and checksum value. Each message consists of a stream of name-value pairs of fields with fields separated by a field delimiter in the stream. All FIX messages are uniquely identified by a sequence number which are initialized at the start of the each FIX session and incremented throughout that session. Each session creates and maintains the sequence series separately independent of one another. With the advent of XML technology, traditional FIX messages described above can be represented in XML called FIXML. The same FIX session level protocol can be used to send FIXML as embedded payload. Currently, the FIXML message structure is defined by a DTDs. A B2B integration between trading partners exchanging FIX messages using J2EE technology is described in the following sections.

5) SWIFTNet (Society for Worldwide Interbank Financial Telecommunication Network)
SWIFTNet provides a wide range of end-to-end Straight Through Processing (STP) of financial messages. These services include trade service services, treasury and derivatives, securities, payments and cash management, custody services and reporting. SWIFTNet provides both B2B and web based messaging services such as FIN (FINancial application) based (using SWIFTNet FIN), structured XML exchange (using SWIFTNet InterAct), file exchange (using SWIFTNet FileAct) and web based messaging (using SWIFTNet Browse). The traditional SWIFT FIN messages are defined using Message Types (MTs), which is based on the evolution of MT syntax and created ISO 15022 complaint MTs. The data representation of field data in the FIN messages is in the plain text format. The MT does not provide structure, meta-data, multiplicity and sequence of the field data. This information called DFD (Data Field Dictionary) is provided in the form of a textual description (similar to a logical data dictionary) in the SWIFT User Handbook. With the advent of XML technology, a XML based standard equivalent to MT tags has been developed. To reduce the verbosity of XML message, this standard is a simplified XML Message (MXs) which is complaint with ISO 20022.

A SWIFT FIN message is represented by its unique identification number having the format of MTnxx, where n stands for the category of the message group and xx stands for individual message. For example, MT1xx represents message used for customer payments. The complete list the categories are shown below.

MT0xx System Messages MT5xx Securities Markets
MT1xx Customer Payments MT6xx Precious Metals and Syndications
MT2xx Financial Institution Transfers MT7xx Documentary Credits and Guarantees
MT3xx Money Market and Derivatives MT8xx Traveler’s Checks
MT4xx Collections and Cash letters MT9xx Cash Management and Customer Status

Table 1: SWIFT message categories.

The structure of FIN messages consists of 5 blocks of data. They are basic header block, application header block, user header block, body and trailer block. In the first two blocks, fields are fixed length, continuous and no field separators. The rest of the blocks may contain sub-blocks and fields delimited by field tags. The user header block is optional, mostly used to hold a reference number for acknowledgment and reconciliation. The body block contains the actual financial data in the form of MTnxx message as described previously. Business application retrieve this body block from the FIN message to process the business logic. The entire FIN message is embedded in a SWIFT message envelope. The SWIFT envelope contains address information which uses X.500 complaint Distinguished Naming (DN) system for representing the hierarchical tree structure, high level and granular entities (similar to LDAP). This enables SWIFT address to define PKI (Public Key Infrastructure) and message addressing and routing to accomplish end-to-end Straight Through Processing. The message structure of SWIFT and FIN message are shown in Figure 3.

Figure 3: SWIFT message structure.

SWIFT uses a secure private network backbone called Secure IP Network (SIPN) to enable the customers to access SWIFT services. SIPN is an IP based secure network connects to a VPN box at the customer side through network partners using Backbone access point (BAP). The SWIFT messages are tunneled through IPSec, which ensures network level security between BAP and VPN box. The session level and message level security of the SWIFT messages are provided by PKI embedded in SWIFTNet Link (SNL). The VPN boxes at the customer side are installed in an M-CPE (Managed Customer Premises Equipment) environment which is managed by SWIFT. A SWIFT Alliance Gateway (SAG) acts as a proxy in the customer DMZ, which intercepts inbound SWIFT messages and routes to application integration interfaces using Remote API Host Adapter (RAHA) for synchronous invocation, MQ Series Host Adapter (MQHA) for asynchronous invocation and File Transfer Agent for file transfer initiated by SWIFT FileAct services. For outbound messages, SAG concentrates the message flow from the application integration interfaces and routes to SWIFTNet through SNL.

As described earlier, SWIFTNet services in B2B integration space are SWIFTNet FIN, SWIFTNet InterAct and SWIFTNet FileAct. SWIFTNet provides a number of messaging patterns for exchanging messages among the trading partners. They are store and forward, Y-copy, T-copy, V-copy, request-response and push-pull model. For more information about these messaging patterns, refer chapter 8 on Messaging Patterns. SWIFTNet FIN enables exchange of traditional FIN messages between customers and SWIFTNet using MT standard. SWIFTNet FIN may use store-and-forward, T-copy or Y-copy as the messaging pattern. SWIFTNet InterAct uses store-and-forward or request-response messaging patterns and MX standard as message exchange. SWIFTNet FileAct uses store-and-forward or push-pull model as the messaging pattern.

B2B integration architecture between trading partners exchanging SWIFT messages with a J2EE based enterprise is described in section Appendix B.9

5) FIX (Financial Information eXchange) Message FlowThe general information about FIX is described in section 3. This section describes the architecture of a FIX based B2B integration involving two trading partners, where one trading partner implement its infrastructure using J2EE and XML technology. Both trading partners have a FIX engine which manages session level and application level protocols. The inbound and outbound architecture is shown in figures 4 and 5 respectively.


Figure 4: FIX based B2B integration with J2EE – inbound FIX message.

Process Flow:
a) The trading partner creates a FIX message using a FIX engine (acts as client) and sends to the FIX engine (acts as server) of the enterprise over leased line, VPN or internet.
b) The request may be intercepted at the DMZ of the enterprise by a FIX proxy server which forwards the FIX message to FIX engine of the enterprise.
c) The server FIX engine establishes a connection with the client FIX engine, authenticates the client by the server engine and sends back the logon confirmation message. Once the client engine receives the confirmation message, it sends the FIX message to the server FIX engine. Since FIX session protocol is based on an optimistic model, no acknowledgment of individual message is sent to the client engine. In other words, normal delivery of message is always assumed.
d) The server side FIX engine retrieves the message and sends to the integration server. If the message is based on traditional FIX message, the FIX message processor maps the inbound FIX message to a canonical flat file schema (at design time). At run time, the inbound FIX message is mapped to the XML instance and sent to the down stream application. If the message is based on FIXML, the FIX message processor extracts the FIXML message from the inbound FIX message and maps to a canonical XML and sends the XML instance to the downstream applications.

Figure 5: FIX based B2B integration with J2EE – outbound FIX message.

e) Once the downstream application completes the business process, it creates a response XML message and maps to the FIX response message. Now the FIX engine of the enterprise acts as a client and sends the FIX response message to the FIX engine of the trading partner.

6) SWIFTNet (Society for Worldwide Interbank Financial Telecommunication Network)This section describes how an enterprise integrates with SWIFTNet and exchange messages. Although there are number of ways SWIFT messages can be delivered for SWIFTNet services, only once scenario describes in this section. The environment of the institution which sends and receives SWIFT messages is assumed to be built on J2EE platform. The J2EE application, using its business logic creates the SWIFT business data. The SWIFT/FIN message handler/processor and SWIFTAlliance Access tools transforms the business data to SWIFT message. The message flow of outbound and inbound SWIFT messages are shown in figures 6 and 7 respectively.


Figure 6: SWIFTNet based B2B integration with J2EE – inbound SWIFT message.

Process Flow:
a) The core J2EE application creates SWIFT business data and marshaled into an XML message and sends to the integration server.
b) The SWIFTAlliance Access or integration interface creates the SWIFTNet FIN protocol envelope message (for MT messages), SWIFTNet InterAct message (for MX messages) or SWIFTNet FileAct message (for file transfer) and sends to the SAG server via Remote Access Host Adapter (for synchronous invocation), MQseries Host Adapter (for asynchronous invocation) or File Transfer Agent ( for file transfer).
c) The SAG server forwards the message to SWIFTNet Link (SNL) which encapsulates the message payload with SWIFT message envelope sand sends it to the VPN box over a TCP/IP connection.
d) The VPN box sends the SWIFT message to the SIPN (Secure IP Network) through IPSec tunnels. These tunnels are established between the VPN box the enterprise and the Backbone Access Points of the SIPN in the SWIFTNet.
e) Based on the SWIFTNet services and the messaging pattern, SWIFTNet servers or the recipient institution process the message and create a positive acknowledgement (or negative acknowledgment) or a response message and sends back to the originating enterprise system as shown in figure 7.


Figure 7: SWIFTNet based B2B integration with J2EE – outbound SWIFT message.

7) Any message protocol over Any transport protocol
In B2B integration, potentially any combination of message standard or message protocol can be used over any transport protocol such as XML over SMTP, flat file over FTP, XML over HTTPS etc. However, each such combination has its own advantages and disadvantages and may be selected based on case-by-case basis. Selection criteria may be based on synchronous or asynchronous, request or response paradigm, push/pull or poll, structured or unstructured data format, compliance of industry standard, level of security and so on. Two of the commonly used and best suited for B2B integration Scenario are described below.

This is the most popular and efficient B2B integration paradigm with out any proprietary components. This solution provides a continuation of current ubiquitous, web based and request-response scenario where HTML pages are sent over HTTP(S). The only difference is that a visual friendly HTML is replaced with a structure friendly XML. A B2B solution can easily be implemented if a similar web application already existing.
Pros:
a) HTTP(S) and XML are open standards and widely used,
b) A wide range of languages and tools provide HTTP(S) client and server implementations,
c) Faster data transfer and minimum overheads
Cons:
a) XML being data and structure friendly than visual friendly, knowledge of XML or third party tools are required for coding.
b) XML being highly verbose, allows eavesdropping by hackers.


Fig 8: Messaging and Transport Protocol
Virtually every vertical industry comes up with a standard which is widely used within the industry. These standards usually provide a Logical Data Dictionary (LDD), a XML data model and a Schema or DTD structure. The LDD provides the complete list of attributes used in the industry and its semantics. XML data model describes the element content model providing parent child relationship. XML schema shows the complete graph of the tree structure. Some of the common standards used in financial industry are given below.

Vertical Industry :  XML Standard
Insurance             :  ACORD
Mortgage              : MISMO
Securities             : FIXML
Trading                 : MDDL
Reporting             : XBRL
Investment and financial research :  RIXML

Apart from the vertical industry semantics, most of these vertical standards provide their own horizontal technological standards such as XML Digital signature, XML encryption, Document embedding, SAML etc. For example Mortgage standard MISMO provide SMART standard for XML encryption and XML digital signature and eMortgage package for document embedding.



Fig 9: Enterprise Service Bus Implementation Using SOAP / HTTPS
__________________________________________________
This document is for reference only. For actual implementation, please contact the author. No part of this document is to be used or reproduced without the written consent from the author (roychettan@gmail.com).