Freigeben über


Jump Starting Payments Integration

The topic of payments system integration has in the past usually dwelled on topics such as real time or batch requirements, message queue interfaces and of course, support for payment standards. All these of course are very important in any payments integration project, whether to support implementation of a new payment system, or the renewal of infrastructure technology. As I visit financial institution customers and our technology partners, a recurring theme appears in discussions about payments integration: simplifying the ‘plumbing’ and the need to know more about what is happening in the environment between the applications.

Complex Plumbing

Payments by nature are a transaction type with a lifecycle spanning multiple internal processing steps and applications. As described on an earlier post there are applications for delivery channels, compliance screening, account posting, settlement instructions, transaction routing and foreign exchange to name but a few. The traditional silo view of operations provides information about a payment at a point in time within an application, and certainly most banks have a well-engineered ‘hand-shake’ between applications to ensure delivery and provide an audit trail and transaction status, but that typically takes a significant amount of development effort to implement and manage.

Payments Message Bus

With the techniques offered using service oriented architectures (SOA), Microsoft has developed IP components to simplify the amount of custom engineering required to implement an integration framework. Our view is to provide the right balance between a flexible toolset and the need to have prebuilt payments integration components that streamline the development effort. The key is to provide value to customers and partners but without being too prescriptive in the solution components. After all, every bank is different but the principle drivers behind integration projects are the same. Using an enterprise service bus (ESB) architecture model, our approach is to create reusable services for common payments integration functions such as transformation, audit trail and tracking, a message database and business activity monitoring (BAM). The result is reduced complexity of solution and integration costs, and the ability to centrally monitor activity ‘between the applications’ for the lifecycle of the transaction.