IFX Service Orientation Study for Payment Processing

IFX Service Orientation Study for Payment Processing

 

Josh Lee
Microsoft Corporation

August 2005

Applies to:
   Interactive Financial Exchange Forum (IFX)

Summary: The IFX Payment Reference is a best practice guide for using industry standards and service orientation. See how Web services can be architected and granularized from the IFX specification using payment processing as a reference. The reference demonstrates the coordination of service orientation goals with industry standard messaging in the banking sector and illustrates how those messaging models and services can integrate into the BizTalk Server business process orchestrator. (16 printed pages)

Click here to download the code sample for this article.

Contents

Introduction
IFX Standard Usage
Service Orientation
Lessons Learned
Best Practices
Payment Interop
Security Issues
Reference Walkthrough
How to Use This Reference
Conclusion
Installations

Introduction

The Interactive Financial Exchange Forum (IFX) was formed as an outgrowth of the OFX consortia many years ago. The OFX consortia focused on delivering solutions and standards for the personal financial management market for consumers. IFX was formed to grow that capability into the business banking, ATM, bank to bank, and payments lines of business. Over the years, there has been great success and adoption of the IFX specification, most notably by a vast majority of ATM vendors and OEMs. Customers and vendors that choose to adopt the IFX specification use it in a number of different ways. But at the core, they are able to use an industry agreed upon data standard and message model for transmitting data inside and outside banking institutions.

Several years ago, when Web services began to grip the technology community, it became apparent that data standards were pivotal to delivering the business message on top of a ubiquitous message infrastructure facilitated by SOAP and XML. In the last few years those data standards have struggled to keep up with the emerging architecture that is now commonly referred to as service orientation. That struggle has taken the form of more granular message-based construction of the business messages, more composable data elements, and leverage of common security frameworks away from proprietary ones.

IFX is no exception to that migration. Current and past versions of the IFX Business Message Specification went through the days of DTD and then early XSD carrying some of the same monolithic structure from the DTD model. Currently, development with IFX is underway to capture the granularization of the message in order to align with service orientation. See also the MSDN article Architecting Industry Standards for Service Orientation for a deeper discussion on the state of standards and current design changes underway with some leading organizations.

Over a year ago, IFX began an effort in collaboration with several other standards organizations in overlapping spaces to define something called a "payment kernel." This core data message would encapsulate a cross-industry agreed upon format that could process a monetary payment from one financial institution to another. This kernel was a base message that could be enhanced, but that in and of itself contained the necessary processing instructions and remittance information to process and payment between institutions. The real value of the payment kernel is in interoperability and industry acceptance for a very important piece of almost any type of transaction. This cross-industry effort is referred to as the IST Harmonization, and has players from the industry in global banking as well as the SWIFT, RosettaNet, and IFX standards.

With the advent of this payment kernel and service orientation, Microsoft began work on a proof of concept to showcase the granularization of the IFX standards and include the payment kernel in a very common business process: that of consumer to bank to bank payment processing. The goals of the POC are:

• Provide a reference for creating service oriented messages from a legacy XML monolithic standard.
• Service factoring reference for the same messages and aligning message payload and service.
• Integration of the payment kernel with WSE security.
• Business processing of IFX specification using BizTalk Server 2004.

The reference documentation, code, and VPC will be made available through various channels on Microsoft Architecture Center.

IFX Standard Usage

In each unique business message of the IFX BMS there can be literally hundreds of data elements. Each message creates a hierarchical representation of an object that is processed during the service implementation. A majority of the elements in each message are optional, so each business implementation makes a decision as to which elements they will choose to use. In the POC, we chose to use just the minimal required elements that were needed to put together a payment message from consumer to bank and from that bank to another bank.

The IFX specification also has a number of business banking messages that assist a bank with internal transaction processing like funds transfer between accounts. The POC demonstrates how those business messages facilitate even new business models in something called No Fail Bill Pay. In this model a customer is protected from overdraft and NSF charges by setting preferences that allow the bank system to discover funds in other accounts and make the appropriate transfers to cover the payments.

The POC required a few steps to prepare the current IFX 1.7 specification for service orientation. First, the business messages that we were using had to be segmented out into their individual request and response message schemas. To support these schemas, we also created two key reference schemas that could be referred to as data dictionaries. One was the holder of the global common types, those elements that were used commonly among all schemas in the POC and of which the IFX BMS is composed. The second support schema is an object library that is specific to that higher level business function: for example, the Payment Object Library.

Figure 1. IFX Standard Support Schemas

The separation of these layers allows for single schema maintenance of the common types, avoiding redundancy and providing better composition for custom messages. And the LOB object library provides a top level node for all the types for a given line of business, allowing the isolation of the necessary elements for the specific line of business.

From the IFX BMS the following messages have been extracted from the 1.7 specification and put into individual request and response message schemas:

• BalInq*—This is the balance inquiry message set used to query the balance in a specified account
• CustPayeeInq*—The customer payee inquiry is used to query the list of payees that the customer has and retrieve properties needed to create a payment
• PmtAdd*—The payment add message is the pivotal message that instructs the bank to create a payment with the data about the payee and customer and apply a debit to the account being paid from.
• XFerAdd*—The transfer add message is an internal message that moves money from one account to another inside of a bank.
• PAIN—The payment initiation schema is the payment kernel previously referenced in this article. It is created from data in the PmtAdd* message.

These are in addition to the object library schemas (used with statements) and the common types. These then are the XML backbone to the POC.

Service Orientation

One of the goals for the IFX POC is to demonstrate service factoring and message-to-service interface alignment. Each of the previously listed messages aligns to a SOAP operation type, with the input being the request message and the output being the response message. In the WSDL, the operations are strongly typed to allow design time binding and discovery in the development environment.

Within the POC there are six services. These services are factored to align directly with the request/response pair previously indicated. For the IFX standard this creates the opportunity for roughly 100 services, certainly not an insurmountable task when aggregated with a central hub like Microsoft BizTalk Server 2004.

Each service is strongly typed with the schema that is extracted from the IFX specification. Each service has an input port that takes the request message and the output port has the corresponding response message. Each message has a correlation ID that allows asynchronous long running transactions to be processed and correlated using BizTalk Server 2004.

Every message aligns with the service that it is contained in. The services that are included in the reference are as follows:

• IFXDemoIntraBankServices.BalInq—checks the balance on a target account.
• IFXDemoIntraBankServices.CustPayeeInq—gets a list of payees and details for a given customer.
• IFXDemoIntraBankServices.DebitAdd—applies a debit to a target account.
• IFXDemoIntraBankServices.PmtAdd—creates a payment object that can be taken in pure IFX form or converted to a payment message (PAIN) for interbank transfer.
• IFXDemoIntraBankServices.XferAdd—transfers funds from account to account.
• PainServiceBank2Service.PainRequest—core payment initiation service, returns acknowledgement from receiving bank.

Not every Web service is used in the solution. For instance there are conditions that check the balance on the target accounts, and if the account does not have sufficient funds the No Fail Bill Pay option is triggered and the funds transfer service as well as the debit account service that follows are invoked. The rest of the workflow is fairly linear, with the end result leading up to a payment message being transmitted from one bank to the other and the acknowledgement being returned.

The Web services are orchestrated using BizTalk Server 2004, which also uses code modules with the orchestration to create the proper messages and schemas for transmission and consumption by the various services. The orchestration is done in a few transactions, first in the transaction that takes care of the intra-bank services like transferring funds, checking payee details, and balance inquiries. The first transaction is completed when the payment is packaged and sent to map to the payment initiation message. The second transaction is the interaction of the payment message with the second bank. This transaction packages the payment initiation message and sends it across with the associated security attached to the second bank and waits for an acknowledgement message.

Lessons Learned

In using a specification architected like IFX 1.X, there are some hurdles to overcome in creating this type of solution.

1. Creating granular messages. The IFX 1.X schema is a single large schema. This schema is also not decorated with a namespace. Each request or response message is an optional element. In order to make this schema usable in a service oriented environment several things had to be done:
   • Create a reference to a global data dictionary for the common types and elements. For the most part, this may already be done for you, such as in the case of IFX.
   • Break up the large schema using a tool like XMLSpy or through custom XSLT to grab all the referenced elements for a particular message set.
   • Group these messages into request and response pairs that can align with the associated Web service operation.
   • Group the request/response pairs into larger logical groupings that you may need to create. For instance, group public services and internal services, or group payment services and account services. These may be delineated by network or function.
2. Global data dictionary. In order to reference the necessary types, we had to create a global data dictionary in a separate schema. This would have seemingly been easy, but the more we dug into the individual message schemas the more commonality we found that needed to be added into the global dictionary. Ideally this would have been done by the IFX group; however, in the 1.X version it has not been. Feedback will be given to the standards forum after this process.
3. There are several idiosyncrasies with the 1.X IFX specifications. Foremost is the fact that most of the elements are optional. This makes the usage of the schemas in BizTalk Server troublesome, as you cannot create designated properties because the elements are optional. In order to overcome this, code behind the orchestration was used to access the elements of the schema that needed to be populated or referenced. This same code behind was also used to handle the mapping from schema to schema.
4. Using IFX within BizTalk Server 2004. Mapping IFX messages caused the BizTalk Mapper to hang, possibly due to the number of optional references. Due to this issue the mapping was done using code. For a schema the size of the IFX messages the code is marginally faster than using the mapper. Doing this also helped consolidate schema processing into one model since no property promotions were possible due to the optional elements.
5. Invoking many different IFX Web services within one transaction makes it more difficult to recover from a failure and roll back the changes. This is largely common for most multi-Web service transactions. However, The IFX schemas must be set up correctly with the correct amount of commonality as a first stage, as it is not a quick change to correct problems later. This means that the common data dictionary should contain everything that is needed to generate the messages, since once defined the schemas are difficult to go back and retrofit with common elements.

Overall, after the creation of the schemas it was relatively simple to generate the class libraries and the types for WSDL inclusion after the fact. The Microsoft Visual Studio environment speeds this process and creates the strongly typed WSDL that is needed as part of the solution.

Best Practices

In creating a solution of this type, it is important that several goals be accomplished:

1. The solution must be interoperable, both in transport and in message definition.
2. The solution must be easily integratable into a development environment for each of integration.
3. The solution must be secure.
4. The solution must provide granular services aligned with the schemas that are also used.

To accomplish these goals, several best practices were used. These best practices are not the only way to accomplish these goals, but are based on good application design and service oriented principles.

1. Creating interoperable services:
   1. Use XML schema for the payload of the messages. This is clearly the place where the IFX schemas are used. In this way at least the message payload is understandable when sent and received on either end.
   2. Web services were developed using Visual Studio.NET and the Web Services Enhancements for .NET 2.0. Each service is expressed using standard WSDL, which is expressed and consumed by BizTalk Server 2004 in the transactions and orchestrations.
   3. The Web services are used over HTTP with SSL.
2. Ease of use within development environment:
   1. Visual Studio.NET 2003 and the BizTalk Server tools were used to create the code and reference. BizTalk can readily consume the WSDL and XSD that were used in the reference.
   2. Visual Studio and BizTalk automate many of the processes for creating Web service proxies, business processes, and code that is generated for dealing with the schemas and integrating them into the business processes.
3. Securing the solution:
   1. This will be discussed in a later section in detail.
4. Aligning granular services and schemas:
   1. Each IFX message was created with a request schema and a response message embedded in each schema. This request and response are in a message type schema that aligns to the data therein.
   2. The Web services are strongly typed through the WSDL that is found in services.wsdl, and each message request and response is mapped to a WSDL operation in this service description file. Each service operation maps to the schema that is also referenced. For instance, the DebitAdd operation uses the DebitAdd_Type.xsd as a payload for the input and output parameters.
   3. The services.wsdl houses the services that are used internally for the bank services, and another WSDL was created for the payment initiation service. This service aligns to the PAIN schema both for payment interoperability and because that service is targeted to always be a public service.
   4. There are a number of permutations and ways to group messages and services for various business reasons. For this reference we chose one way, when others could very easily exist. One guideline that is important is to differentiate between public and private services. In this reference, since many services were internal to the first bank (like funds transfer, payee lookup, and so on) those were used in a separate WSDL from the clearly public payment initiation message.

Through following some of these best practices it is possible to create a service infrastructure that is flexible and allows for ease of integration through a common development environment. It also allows the architect to create points during which the solution can be scaled and augmented with additional services. One item to note about the reference solution is that we did not attempt to fill in all of the elements in every schema. Many of the elements are bank or account specific and can be filled in as customization occurs. It was our intent to showcase the elements only needed for transmission, security, and account and amount identification. Customization in the code behind the BizTalk orchestration can continue to fill out the elements that are needed for a specific implementation.

Payment Interop

The main goal of this reference is to provide the interop of the payment message. This is the key message that goes between two (or more) financial institutions. The most important thing to interoperability is understanding the format and data inside each message.

We used the payment kernel that was created as part of the joint industry effort. This payment schema is (aptly) called the PAIN.xsd. The PAIN schema is the one that flows from bank to bank as part of the payment transfer request.

In order to create the PAIN schema, the IFX PmtAdd message was used to map to the elements into the PAIN schema. For two banks using the IFX standard, all that would normally be required would be to use the IFX payment message. However, since it is not guaranteed that they would be both using the same standard, we use the PAIN schema as the top choice for transmitting a payment.

The complete drilldown for the PAIN schema and schema usage is governed by ISO and can be found at http://www.iso20022.org. Additional details on payments architecture and standards involved can be found at the following links:

• SWIFT Financial Dictionary—http://www.swift.com.
• SWIFT Standards modeling—http://www.swift.com/index.cfm?item_id=41663.

In the solution we used the following basic workflow.

Figure 2. Payment Solution Workflow

The only part that we did not cover as part of this solution is the Remittance Advice stage between the non-bank parties. This could easily be accomplished using a Web service that was hosted by the final party noted here. The credit advice or bank statement from the final agent to the final party is stubbed out using an SMTP mechanism in the workflow rather than creating a separate entity to host the final party Web service. IFX has a bank statement message as part of the standard that is not referenced here, but could be used at a later stage by adding those messages in the same way that the messages were created for the solution already.

The PAIN schema can be part of a much larger and complex payment workflow not covered as part of this reference. This entire workflow can be found at the websites previously listed.

Security Issues

Without a doubt, the banking sector is the most secure and has the need to remain so. Any solution that processes payments would need to be secure as well. In this reference we used the WS-Security standards to provide a digital signature and encryption of the message between the banks. A bank would have a unique digital certificate that would provide the security necessary to send the message over the wire.

The first item that needed to be secure was the consumer portal or application to the bank. In the case of this reference we used a rich client Windows application calling a Web service. The communication from the consumer application to the Web service that initiates the payment is secured in two ways: first, the transport is secure using SSL over HTTP. Second, the message is secured with WS-"Username" in which it is signed with a token that is generated from the username and password that the user entered. The username/password combination is validated against the database on the server side to ensure the customer is valid, aligning well with authorization routines.

The second set of points that needed securing were the communication from one bank to another bank. This was also done using SSL over HTTP. In the case of the bank-to-bank communication, we also used WS-Addressing to route the message and then, using the WS-Security and WS-SecureConversation pieces of WSE, we were able to secure the message, as well, by using a secure token issuing service. This is all covered using the WSE SDK code, which allows you to create a token issuing service and houses a test certificate. Please see the setup documentation at the end of this document for details on setting up the development environment.

Please note that in order to send secure messages over networks like the SWIFT network, additional security or authentication features or elements may be required. Please refer to SWIFT or other documentation for necessary security requirements.

Reference Walkthrough

The overall reference is not very complex from a user experience standpoint. In fact, the code and workflow is fairly straightforward, as well. The complexity comes in the manipulation of the data and IFX schemas that underlie and integrate with the Web service messaging.

After a simple username/password login screen, users are presented with options for paying their bills. The payee list is generated from an IFX message that requests the payee list from the bank. An account list is also generated with the available funds near the name of the checking accounts. In figure 1, you will notice that the available funds are set at $0. This is done on purpose to demonstrate a new concept referred to as No Fail Bill Pay. The No Fail Bill Pay is a mechanism that the bank uses to allow users to have a fail over checking account in the event their main account is low on funds. This is different than overdraft protection or credit lines since there are no fees, interest rates, or service charges; the bank simply checks for the no fail option and, if needed, will debit the failover account instead. This is an important new feature, especially for those who may not be near a computer and still have automated bill payments coming from their account.

The user enters an amount in the amount field and presses the "Pay" button to initiate the workflow.

Figure 3. Payment Initiation

The process actually begins before the user clicks the Pay button. By this time there have been a few calls already made to the first few Web services to get the payee list and accounts populated in the drop down lists.

After the user clicks the Pay button, the following steps are taken using BizTalk Server orchestration (orchestration file attached to this document):

1. Invoke the orchestration with a receive function of the formatted payment message. This message is formatted by the client side application and sent to the payment Web service.
2. Start a transaction to process the payment.
   1. First the funds are checked in the target account and the presence of the No Fail Bill Pay option is validated.
   2. Step "a" is done through a BizTalk policy.
   3. Funds are checked; this validates the target account and the no fail account.
   4. Success debits the target or failover account.
   5. A response to the "payment add" Web service is sent back to the client after the message is constructed.
   6. The IFX message elements are then mapped using another policy into the PAIN message and that is sent across to bank 2 to complete the transaction.
3. The next part of the workflow receives acknowledgement from the second bank that the payment message was received. Since this is a long running transaction, the payment Web service is hosted by bank 1 and allows bank 2 the ability to call back with the correlation numbers needed to coordinate the acknowledgement.
4. Final steps are e-mail messages that are stubbed for notifications. These would likely be replaced with remittance advice messages to the final parties, as previously noted.

When these steps are complete the user is given a reference number and the debited funds are reflected in the drop down list box and the demonstration is complete (see Figure 2). The solution uses a simple SQL Server database to store the values and balances as well as the payee information and customer information.

Figure 4. Payment Completion

After all is said and done, the messages are the most important part of this solution. The hardest portion of this solution was to break up the messages into smaller service oriented pieces. Obviously it's much easier to assemble from scratch from smaller pieces.

How to Use This Reference

There are a few ways to look at this reference. First, it should be noted that each bank or service provider has different ways in which they process payments and interact. Those unique ways are not encapsulated in this reference, but there are also many organizations that struggle with the tasks of implementing industry standards. Especially in the realm of service orientation and the ever evolving Web services landscape, it can be difficult to come up with the right way to factor services, create payload schemas, and orchestrate a business process using everything discussed previously in this article.

Use this reference as an example in the following areas:

• Service factoring—one of the difficult areas in a service oriented architecture is deciding how best to factor a Web service to accomplish exactly what you need it to do and no more or less. The reference provides guidance on banking services that align with the messages in the IFX specification for creating a service aligned with the payload of the service.
• Payload creation—since many legacy XML standards were not created with Web services in mind, it is difficult to retrofit a WSDL typing architecture with a large monolithic standard. This reference shows how a schema can be segmented from the larger specification to create a service message that aligns with the Web service.
• Payment process—While not a canonical or compliant payment process, as there are some data elements missing, it is a viable reference for how the IFX payments messages can be broken up in one way to ensure secure delivery over secure channels. This reference example can be used with other payment references to assemble a compliant and implementable payment solution or similarly architected industry solution using messaging standards.

Conclusion

The banking industry is rife with the ability to expose services and provide service orientation. Using the IFX standard is a great start to the backbone of a service oriented solution using industry standards. With only a little work, to break the schema into usable pieces and to create services for each business message, a rich tapestry of services for internal and external bank usage can be created. Together with the base communication standards used in Web services, these solutions can form an entire enterprise service interface library. While this reference only showcases a few of these services and messages, with the same process, several dozen or more services can be created with the IFX standard as the basis. As the standard develops, even more services will be made available for branch banking, business banking, and enhanced ATM services for a holistic enterprise banking experience.

Installing and Configuring Your Development Environment

Pre-Installation

Software Requirements:

• Microsoft Windows Server 2003
• IIS 6.0
• .NET Framework 1.1
• SQL Server 2000
• BizTalk Server 2004
• Microsoft Web Service Enhancements (WSE) 2.0

Installations

Now that you have successfully installed all of the pre-installation software requirements, you are ready to install the reference implementation components on your development computer. This section details the procedures to install and configure the Windows installer package for the reference implementation.

Installing the Reference Implementation

The procedures listed in this section install the reference implementation components on the development computer that now contains all the pre-requisite software mentioned in the "Pre-Installation" section earlier in this chapter.

To install the IFX reference implementation components:

1. Double-click IFXDemoInstallation.msi to install the reference implementation.
2. Click Next.
3. Install the reference implementation in the default location, or you can browse to a new location for the installation.

Set up the Demo e-mail settings:

1. Open C:/Program Files/Microsoft Developer Resources/IFX Reference Implementation/Server/Server/IFXDemoHelperLibrary/Helper.cs in notepad.Set.
2. Set smtpServer, fromAddress, toAddress.
3. Save the Helper.cs.
4. Edit C:/WINDOWS/system32/drivers/etc/hosts.
5. Add 127.0.0.1 contoso.com.
6. Add 127.0.0.1 bank2.com.
7. Save hosts file.
8. Look up the identity of the application pool the IFXService virtual directory is running under.
9. Ensure the identity has dbo_owner permission to the IFX_Demo database.
10. Also ensure the identity user is a member of IIS_WPG and "BizTalk Isolated Host Users."

To run the setup file:

From the C:/Program Files/Microsoft Developer Resources/IFX Reference Implementation/Setup directory run Setup.bat.

Uninstalling the Reference Implementation:

From the install directory (default C:/Program Files/Microsoft Developer Resources/IFX Reference Implementation/Setup), run Cleanup.bat.

To remove the reference implementation:

1. In Control Panel, click Add or Remove Programs.
2. Click Change or Remove Programs in the left pane.
3. Click IFX Reference Implementation in the right pane, and then click Remove.
4. Complete the task by clicking Yes in the dialog box.

Post Installation

Enabling WSE

By default, the reference implementation ships with WSE policies in a disabled state. The WSE policies are set up to use the sample X.509 certificate that ships with WSE 2.0. The communication between the client and BizTalk Web services uses UsernameSigning. The PAIN bank-to-bank Web service uses WS-SecureConversation. It is recommended that you get the entire testing process to complete without errors before enabling WSE.

To enable the WSE support:

1. Open C:/Program Files/Microsoft BizTalk Server 2004/BTSNTSvc.exe.config in Notepad.
2. Paste the following code in the section to the beginning of the file if not already present:

3. Recycle BizTalk Server: Start/All Programs/Microsoft BizTalk Server 2004/BizTalk Server Administration/Servers/.
4. Right-click BizTalkServerApplication, and click Stop.
5. Right-click BizTalkServerApplication, and click Start.
6. Next, uncomment the section and save the following files:
   • C:/Program Files/Microsoft Developer Resources/IFX Reference Implementation/Server/ Server/PainServiceMainBank /web.config.
   • C:/Program Files/Microsoft Developer Resources/IFX Reference Implementation/Server/ PainServiceBank2/web.config.

Installing the Sample X.509 Certificate:

Included with WSE 2.0 are two certificates for testing purposes.

To install the test sample certificate:

1. Click Start, click Run, type mmc, and then click OK.
2. On the File menu, click Add/Remove Snap-in, and then click Add.
3. Double-click Certificates under Snap-in.
4. Click Computer account and select Local computer.
5. Click Finish, and then close the dialog boxes.
6. In the management console tree, under Personal, right-click Certificates.
7. Select the All Tasks menu and click Import to open the Certificate Import wizard.
8. Click Next in the wizard.
9. For the file to import, select the Server Private.pfx file in C:/Program Files/Microsoft WSE/v2.0/Samples/Sample Test Certificates and click Next.
10. For the password, enter wse2qs and click Next.
11. Select Personal as the certificate store and click Next.
12. Click Finish to install the certificate.

This certificate is signed by the test root agency, thus the allowTestRoot attribute is set to true for the configuration element in the Web.config files provided with this reference implementation. The sample certificate should be used for testing purposes only.

In order for WSE to obtain the X.509 private key from the local computer certificate store, it must have permission to do so. Enter the account number under which the Web services are running (the same as the process identity of the application pool), and read access to the file containing the private key.

To obtain the X.509 private key from the local computer certificate store:

1. Open the WSE X.509 Certificate Tool from Start/All Programs/Microsoft WSE 2.0/X509 Certificate Tool.
2. Set Local Computer as the certificate location and enter Personal as the store name.
3. Click Choose Certificate, select the WSE2QuickStartServer certificate, and then click OK.
4. Click Private Key File Properties, click the Security tab, and add the user accounts under which the Web services and BizTalk services are running.

For more information, read "Managing X.509 certificates" in the WSE 2.0 documentation.

© 2005 Microsoft Corporation. All rights reserved.