17 September 2014

68780

Ganesh Guruvayur - Polaris Software Lab Ltd

6 | posts 13,484 | views 0 | comments

Centralized Payment Exception Management

04 January 2014  |  1932 views  |  0

Centralized Payment Exception Management – Why do banks need to care?

Banking industry is witnessing a heightened search for efficiency in payments work stream. Payment strategists have carefully analyzed the business services that are central to different payment workflows and their distribution across different participating systems in the payments landscape in banks. Their close scrutiny has unveiled a variety of business exceptions that are routinely handled in these systems, forcing banks to dedicate resources to manage the exceptions, losing standardization in the way the exceptions are viewed. The phenomenon of ‘Islanding’ around these systems has caused loss of central control and visibility of the payment flows. Studies have revealed that exceptions management makes a significant portion of the payments transactions costs. This has led to advocacy of the concept of centralized payments related exceptions tracking and management. Centralized exceptions management can be safely looked upon as the beginning of better exceptions management.

Exceptions are like ‘afflictions’

Exceptions can be looked upon as afflictions that are dispatched to break down the payment process. It is important to understand their periodicity, severity and their specific resolution. Statistical modeling of the exceptions may give clear patterns in terms of the specific customers, payment file formats, currencies, counterparties, payment types, charge codes, networks etc that are the carriers of exceptions. These patterns are usually help in establishing preventive rules as well as rules for the intelligent automated resolution of the exceptions. Exceptions

Catch Them Early:

It is important to classify exceptions as ‘show stoppers’ and ‘irritants’. The show stoppers are relatively ‘good’ as they stall the payment order in its tracks and prevent further investment of time. It is important to have the show stoppers identified very early on in the payment flow than later. The later they are identified the more the waste of processing resources.  Good payment platforms invoke a variety of rules to validate the payment orders and identify the show stopper exceptions at infancy. They also trap as many irritant exceptions as they can. Irritant exceptions would need to further be characterized as those that can be decisioned objectively through engagement of rules and those that require human intervention. Those that require human eyeballing are the ones that are the real culprits as they sap most of the organization’s energy, time and stack up the transaction processing costs.

Which system is best suited to host centralization?

A Payments Services Hub is usually seen as an ideal place to gather exceptions from the various systems role players for multiple reasons.

  1. A payments services hub has comprehensive inter linkages with all payments assembly line systems including all the different payment engines that a bank may have.
  2.  It carries the ability to interface with these systems on a real time basis.
  3. It has the ability to orchestrate the flow of a payment order through the various systems as per a predetermined payment process map.
  4. It has the ability to identify different originating channels, side stream and downstream payment systems, their role play, and their exceptions.

Using First Principle approach to self diagnostics

Creating an inventory of exceptions serves as a good starting point for each bank to understand its unique exceptions mix. This also helps in normalizing the exceptions across different payment assembly line systems and creates a uniform interpretation for each exception. Centralization of exceptions facilitates collecting MIS around spread of exceptions and help banks understand the breakup of the volume of exceptions in terms of some of the following:

-          Payment flows that are more prone to generate exceptions – outward direct debit / credit, inward direct debit / credit, refund, recall, return etc

-          Which of the specific payment life cycle stages out of the many such as order management, order authorization, order warehousing, FX conversion, payment execution, payment message building, network release etc for an outward remittance, that generate the most exceptions

-          Domestic vs cross border payments

-          Current vs Future dated payments

-          Retail vs wholesale payments

-          On-us vs third party payments

Challenges to Payment exceptions centralization:

While there are obvious benefits to centralization of payment exceptions, there are numerous challenges:

-          Costly online interfaces to be established with ancillary systems to enable real time visibility and resolution

-          Requires extensive deduping of exception types to ensure that multiple exception codes are not present to handle the same condition

-          Creation of dedicated exception queues: A good payment services hub is required that allows creation of separate queues dedicated for each exception category

-          Requires heavy data exchange between the subsidiary payment system and the payment services hub to support an elaborate view of the exception condition and the data required for human resolution of such exceptions. For example insufficient funds as an exception, requires the bank user group to be able to see customer relationship, average account balance maintained over past periods, number of instances of insufficient funds created in the past, the purpose of remittance etc to be able to decide on whether the insufficient funds condition is to be overridden by granting a temporary overdraft or to be rejected.

-          Breakdown in the online interface can result in pile ups of the payment order at that specific stage locking down the specific payment process flow till the link is restored. For instance, if the bank had a batch handoff of payment orders for OFAC check to the OFAC system, replacing it with an online bidirectional link with the OFAC system would get the OFAC hits and suspect hits into the payments hub for override decisions but create susceptibility due to link failures

-          Requires ability to invoke exception linked approvals – A good payments services hub overcomes this issue through the presence of robust approval framework. It allows setting up of additional approval levels and tie them to exceptions. The system automatically queues up payment orders into a supervisor queue for out of turn approvals, whenever the particular exception is overridden.

-          Alert generation: When exception management is distributed, the subsidiary system carries the responsibility to generate alerts when exceptions are encountered. Moving the exception management to a central system puts the onus of alert generation on to the central system. The payment services hub in such a case is required to have configurable exceptions management capability that is agnostic to the exception category and amenable to parameterization of exception linked, multi party, internal bank facing and in some cases client directed notifications

 

Conclusions:

Centralization of exceptions leads to other benefits such as single point feed to payment dashboards, surveillance of payment business services, efficient payment process flows leading to resource optimization etc. While we drool about the benefits of centralization of payment exceptions tracking and management, it is important to not lose sight of the need to preserve existing investments in payment assets.

 

TagsPaymentsTransaction banking

Comments: (0)

Comment on this story (membership required)
Log in to receive notifications when someone posts a comment

Latest posts from Ganesh

Creating A Supply Chain Aware Payments Platform

13 January 2014  |  2464 views  |  0  |  Recommends 0 TagsPaymentsTransaction banking

Centralized Payment Exception Management

04 January 2014  |  1932 views  |  0  |  Recommends 0 TagsPaymentsTransaction banking

Multi Banking - Domestic Environment

02 January 2014  |  1907 views  |  0  |  Recommends 0 TagsPaymentsTransaction banking

Partner Finance - Syndication in SCF

02 January 2014  |  3006 views  |  0  |  Recommends 0 TagsWholesale bankingTransaction banking

Creating Revenue from Corporate Payments Decision Support

02 January 2014  |  2200 views  |  0  |  Recommends 0 TagsPaymentsTransaction banking
name

Ganesh Guruvayur

job title

VP, Head, Hub Solutions

company name

Polaris Software Lab Ltd

member since

2014

location

New Jersey

Summary profile See full profile »

Ganesh's expertise

What Ganesh reads
Ganesh writes about
Ganesh's blog archive
January 2014 (6)

Who is commenting on Ganesh's posts