Challenges around STP in Payments

Straight Through Processing (STP) has gained prominence in the world of electronic payments, with banks the world over, closely analyzing their payment processes to evaluate the STP rates. Banks have witnessed payments business getting commoditized with increased competition and shrinking revenue flows. Post 2008 crisis, increased focus on consumer financial protection has forced banks to introduce a whole lot of transparency in their fees and charges. This has led to more visibility in the fee catalogues of banks and also pushed them to reduce fee pricing. This has made banks to look inwards and discover ways to cut the cost of transactions. Payment processing being the primary transaction banking business for banks, has come up rigorous scrutiny from that standpoint and explains the vigor with which banks are pursuing STP in payment processing. Every break down or pause in the payment process represents prolonging of the payment completion cycle time. This is closely tied to the transaction cost.

What causes a Payment cycle to elongate?

Client causes

1. Missing core pieces of payment information:

Clients routinely miss out supplying vital information to its bank for payment message building. This causes the bank system to struggle while building the payment message causing the payment order to get into an exception where it could be repaired or rejected depending on the severity of the condition.

1. Out of Band:

Good payment platforms allow banks to store the payment preferences and prohibitive clauses shared by a client with the bank. During the in-flight processing of payments, the system compares the payment request with the client preferences and restrictions to check for deviations. These deviations could result in the payment being viewed by the payment platform as anomalous causing it to get into a manual review queue where a back office user could contact the customer to verify the request or taking additional time to confirm its authenticity

1. Duplicate Requests:

One of the basic requirements of a Payment platform is its ability to detect a duplicate payment order. Attributes used for duplicate check can be dictated by a client. In case of a bulk payment order submitted in the form of a payment file, the duplicate check is more complex. It may start by checking the file header, then the batch header and finally individual records in the batch. An entire file can be marked as duplicate or a batch within the file or an individual record. File level duplicate checks are more challenging as the system looks for an exact replica of a previously submitted payment file. A duplicate check can be based on exact match or likely match. Exact match result in lesser instances of duplicate items compared to likely match. More the number of attributes set in the match rules lesser the number of duplicate items. The scan may be for payment traffic originated by the client in a day or may even go across days. The broader the period of scan more the chances of payment order getting marked as a suspect duplicate.

1. Invalid account conditions:

A client is responsible for ensuring that the account on which a payment order is requested carries a valid status. While posting the debit on to a client’s debit account or credit for a direct debit, the payment system usually interfaces with the accounting system to validate if the account carries valid status. Some examples of invalid account statuses are closed account, inoperative / dormant account, account blocked, account stop pay. These lead to break in the payment process causing the payment order to get into an exception queue. Inside such a queue, depending on the severity of the exception condition, a back office user in the bank may either override the exception or reject. Overriding the exception further convolutes the flow requiring additional approvals that get called for stretching the path to the network gateway.

1. Insufficient funds

A client originating a payment is required to make ever funds cover available through own funds or sweep in provider balances or credit limits dedicated for payments. Insufficient funds causes the payment to move to a referral queue thereby obstructing the payment passage

1. Invalid Debtor Mandates for direct debits

Certain types of direct debits require a mandate based authority to be in place that needs to be validated before the direct debit can be originated. Mandates need to be validated for the transaction currency, validity period, debtor id, underlying contract id, frequency of direct debits and such other aspects. Mismatch of the direct debit with respect to the mandate halts the movement of the direct debit

Bank causes:

1. Payment approval and review:

Bank may enforce dual control or multiple approval layers before a payment is released. This leads to break in the smooth flow of the payment order due to queuing of the payment order in approver queues. The payment platform may allow the bank to design different types of queues based on purpose codes (such as tax payments, payroll etc), currency, value of the payment, value date, proximity to network cutoff etc. The queuing of a payment order is based on the routing logic to determine which queue it should be routed too. Inside the approval queue, the ordering of the payment orders can be based on the payment priority that is stamped.

1. Payment enrichment:

Bank may take up enrichment of a payment order through setting up of automated enrichment rules. These rules can append data or replace data elements in the original payment order. Depending upon the extent of enrichment, the bank may set up rules on the payment platform to seek client concurrence on the enrichments. When the payment order is sent for client approval it leads to break in the payment flow.

1. Interdiction Checks:

Regulatory pressures requires originator banks to use stringent checks to ensure that the counterparty, counterparty bank, destination country are not on OFAC or AML list or on bank’s internal hot list. This requires the payment order to be moved to an external application outside of the payment platform for sanctions check. A payment platform is required to have strong orchestration capabilities that enable it to move a payment order through an online interface to another application and bring it back along with the output from the external application. Absence of interface orchestration causes the suspension of the payment order and converts interdiction check into a manual activity thereby disrupting the payment’s straight through processing.

1. FX orchestration:

One of the critical preprocessing functions of a payment order is to validate if the payment order requires FX conversion due to mismatch between the remittance currency and the debit account currency. If it does, the payment platform decides if it needs to use daily rate cards or negotiated exchanges stored underneath forward contracts that the ordering customer has purchased. These may require fetching the applicable exchange rates via interfaces with Treasury applications or moving the payment request to a queue where a bank user manually attaches an exchange rate. The latter is a clear example of breach of the payment flow. An evolved payment system has the ability to manage such financial conversations with side stream systems. They can handle complex conditions such as selecting one exchange rate contract out of multiple contracts that a customer has purchased through invocation of rule sets that are configured for specific clients.

Measures of STP:

Following are indicative of the STP index witnessed in the payments desk in a bank:

-          Average payment cycle time

-          Average time taken at each of the stages set up within a payments process

-          Percentage of payment orders of the total payment orders received in a day, that are routed to exception queues

-          Percentage of uptime of mainstream payment business services

Factors that enhance Payment STP:

-          Substituting manual data transcription / validation with online interfaces.

• For instance capture of payment amount, currency and account number into a DDA system to fetch account status and funds availability can be replaced with an online interface touch point with the DDA system

-          Rules driven business services such as the following

• Payment order validation,
• Order enrichment,
• Payment type determination,
• Queue routing
• CSM resolution
• Funds coverage determination
• Exceptions management

-          Reference data store

• Create internal references for as many reference datasets for which external system handshake is needed and eliminate corresponding online interface touch point
• For example a payment order requiring FX conversion can be supplied internally stored exchange rates that have been batch fed from the Treasury system
• Some of the data sets eligible for capture within the reference data store available in a payments platform are as below:
  • Customer ids, account numbers and their inter linkages
  • Customer payment preferences
  • Currency codes, currency pairs, exchange rate types, exchange rates
  • Service charge codes, computation logic
  • General Ledger codes
  • Invoice data, utility company data, subscriber data, tax codes
• The bank has to weigh the benefits of elimination of online interface touch points with data duplication and data sync

Conclusion:

Banks don’t have to necessarily wait for a major payments platform overhaul to nudge the levels of straight through payments processing. Progressive focus on payment process efficiency usually leads to quantum leap in payments STP. A positive rub off from this is helping the bank create its payments strategy blueprint.