Corporate Payments are characterized by large value and time sensitivity unlike retail payments that are low value and non urgent. The large value of corporate payments makes it mandatory to ensure that they are backed by funds and every attempt is made to see them through.

Automating Payment decisioning

Banks are increasingly looking for automation in the area of payment decisioning. The payment decision support application is positioned in between the channels and the payments engine. It may be a part of the payment services hub or can even be a separate component that co exists with the payment hub. After a payment hub has completed pre processing the payment order, when it comes to the account debit, the payment decision support tool is invoked. Many banks prefer invoking the payment decisioning before handoff to the payment engine. Payment decisioning usually deals with a Go / No Go decision. A Go usually means the Payment Order is adequately backed by funds while a No Go points to funds insufficiency.

What is the basis for a Payment decision?

A payment decisioning application is required to interrogate the payment order to resolve the host account on which the debit is presented. This usually deals with identifying the ordering customer as well as the ultimate owner of the payment order. If the two are the same, checking further to see if the debit account belongs to the customer. If the ultimate owner of the payment order is different from the ordering customer, checking to see if the debit account belongs to the ultimate owner customer. This is followed by understanding the background profile of the account in terms of whether it is part of an account group with other accounts backing up the account in case of deficiency of funds. If there are such accounts, checking if the bank has authority to access such accounts. The authority to access funds in the other supporting accounts manifests in the form of a sweep instruction on the other accounts directed to the debit account so as to pull funds from them into the debit account in case of need. Going further to check if the account has got payment limits configured. Limits could be layered meaning hierarchical. Payment preferences of a client can indicate the draw preference in terms of whether to sweep funds and then use payment limits or limits first and then payments. It is obvious that using own funds parked in investment accounts may save debit interest applicable on using credit limits granted by the bank.

Value of reference data store

Many payment platforms do not carry robust reference data stores to house the data related to client preferences, restrictive clauses, limits and sweep structures and therefore are required to invoke costly interfaces to fetch the data from master limits and accounting systems. This impacts the STP process and increases failure points depending upon how many online interfaces are involved in getting the data for decision making process. A strong payment platform allows storing of critical data elements that can be referred natively for accelerating the payment decision. They let the banks decide how the reference data is to be populated and even allow designing bulk file formats for different data loads coming from different sources in the bank’s landscape.

Backing a reject decision

Storing a snap shot of the balance and limits data to support a reject decision is of immense value. This helps the bank substantiate and justify the rejection of an outward payment on grounds of insufficient funds. There may be instances of customer releasing large payments in anticipation of incoming credits to their accounts. Number of funds retries performed on the debit account and associated balance / limits availability scan across the account and limit clusters linked to the debit account is a service that banks consider worth associating a pricing event with. Each attempt can result in a notification going to the client and the RM carrying results of the retrial run. The bank takes all the precaution before the payment request is abandoned.

Pitfalls of Payment Release Keeping in view Pipeline credits

There is an element of credit risk involved when a bank includes pipe line funds and investment accounts in the funds aggregation routine to decide over payment release. A good payment decisioning system looks at the pipe line funds and breaks it down into separate value dates to narrow down only on those unclear funds that are coming due the same day as the payment release date. This ensures that overdrawn positions are not created between the payment release date and clear credit getting applied to the debit account. Similarly when releasing funds against invested funds it is a good practice to ensure that the investment breakages are routed through the debit account or atleast the credit account has a negative hold is created and is in the same cluster as the debit account on which payment has been originated.

Other considerations:

While a bank considers it imperative to include all large ticket payments emerging from all channels from an automated decisioning perspective, it may not always to be able to do so in the first step. A good thought in such cases is to include those channels from where the high value traffic is the highest and eventually covering all the others.

End State Maturity:

Banks that have embarked on the path of automated payment decisioning, can choose to include outgoing payments,  inward direct debits and eventually move towards creation of a generic debit decision support framework that covers transfers and other types of debits that are presented on their Global Transaction Banking (GTB) client accounts. The reduction in instances of funds insufficiency linked payment failures achieved through the rigor available in an automated payment decisioning solution can appeal to corporate clients and can be positioned as a value add by banks striving to open up new fee based revenue streams.