Before the pandemic hit, many larger institutions considered launching real-time payments (RTP) to be at least somewhat challenging. The process requires multiple front and back office systems, as well as various operational groups. And these systems and groups always need to be in sync in order to process a successful transaction in real-time.
Since then, however, corporate awareness has grown, as financial institutions were forced to adopt the on-demand technology that became increasingly necessary to provide an above average customer experience. And honestly, it wasn’t as difficult as most institutions thought. Once connected to RTP, any institution can receive a real-time payment.
To further discuss the modernization of back office processing and how businesses can make their technology real-time payments friendly, PaymentsJournal sat down with Dr. Jack Baldwin, Chairman at BHMI and Steve Murphy, Director of Commercial and Enterprise Payments Advisory Service at Mercator Advisory Group.
What’s the issue: modernizing back office processing in a real‑time payments environment
From the perspective of BHMI, the biggest issue with modernizing back office processing in a real-time payments environment is that the back end of a payments network cannot keep up with the real-time front end.
The goal of real-time payments networks is to transfer funds from the originator to a recipient within a matter of seconds. Creating an interface that accepts payment information then posts it to a real-time payments network is a relatively simple process. For example, smartphone users can key their payment information into an app like WeChat Pay, hit submit, and post that transaction to the network in a few seconds time. But unless the transaction has been settled, this is only the beginning of the process.
This is where the problem with back office systems begins. “The back office is where real time meets batch in a typical processor back office environment,” explained Baldwin. “For example, [the] typical back office system [is] going to create batches of funds, transfer transactions, and process them to settlement at various times of the day—maybe one time a day, maybe multiple times a day. But whatever that number, it’s not real time. And it’s not keeping up with the arrival of the real time transactions from the front end.”
Here, the back office is not keeping up with the arrival of the real-time transactions coming in from the front end. And what this means is that the back office can’t provide the same real-time processing and reporting services that are necessary to complete faster payments processing. Thus, back office transactions can only produce results that are accessible at the end of a settlement period, which could be once or multiple times a day.
Consequences of a batch‑focused back office
Every issue comes with a set of consequences, and back office processing is no exception. With this type of payment processing method, recipients of funds can’t use that money without restriction until a final settlement happens. Because of this, payments can be canceled between the time of initiation to the point of settlement, which makes the transaction susceptible to potential fraud.
Instances of this happen often with older wallet‑based systems, like Venmo. Baldwin offered his own example: a buyer acquires an electronic, downloadable good, such as concert tickets. The seller does not release the download until they have received the payment notification. However, when the buyer submits the payment to the wallet network, the seller receives a message that the transaction was processed and the money was received. Then, the seller releases the electronic tickets, but the buyer still has time to remove the funds from their own account before they are withdrawn for the transaction. When the settlement takes place, it ultimately fails, leaving the buyer with tickets and the seller without compensation.
“So you have a fraudulent situation with this dichotomy between the origination of the transaction payment transaction and the settlement of it,” elaborated Baldwin. “But one of the things that we see with our clients is there’s a lack of visibility into the state of payments processing during the course of the processing day until settlement has occurred.” Lack of visibility has been cited often by clients as a major consequence of back office payments.
BHMI’s Concourse software suite addresses the real‑time back office problem
BHMI likes to solve problems for its clients, and modernizing back office processing is certainly one of them. BHMI’s Concourse Financial Software Suite® works to remove the batch-focus from back office processing so it better matches the front end. “Concourse is an integrated set of back office products that supports near real-time settlement,” defined Baldwin.
All of the Concourse modules are rule based and support a continuous processing architecture. This means that Concourse can process any transaction, regardless of the type and where they come from. User results and reports will be available almost instantly, within seconds after the transaction reaches the back office. “So Concourse will accept the transactions and store them in a repository, and it’ll process them to completion in near real time,” elaborated Baldwin. No transaction batching will take place before the final payment processing occurs.
It works this way whether or not Concourse is the funds provider. If it is providing the funds, then movement instructions are generated for each individual payment as it arrives. If there is a third party moving the money, then Concourse can process the transaction up to the movement of the finances, at which point it is handed over to the outside system, like ACH or RTP.
Regardless of where the transaction is finalized, all the details of the payment are recorded, and the repository and settlement positions are automatically adjusted to provide an accurate summary.
How companies “future proof” their payments environment
Predicting the future is hard, which is why BHMI created an architecture with flexibility. Its software can accommodate most new payment features without having to scrap a client’s original foundation, maximizing efficiency.
“All the modules are rules driven; we have an industrial strength rules engine that underpins all of the concourse modules,” said Baldwin. If clients have changes that must be made because of a new feature or transaction type, they can be accommodated by simply adding updated or modified rules and configurations; there is no need to rewrite code. The continuous processing capabilities allow BHMI to accept new real-time payments and batch payments when they arrive and process them as far as possible.
Most back office processing systems can accept transactions from a multitude of sources, and these transactions often have common data elements to gain better control over their environment. Back office processors frequently map common data elements from various sources into a standardized form. “And these forms are the ones that are actually processed going forward,” continued Baldwin. “But in so doing, sometimes you lose some granularity of information associated with the original data element that somehow you’ve now abstracted out while you [were] mapping it to some standardized form.” If new functions or features are added that require extra levels of granularity, they may be lost.
BHMI gets better control over its environment by mapping similar transaction in canonical forms, while also using raw transaction data. There is all of the original data that arrived with each individual transaction, so if a new feature requires raw data, it already exists and it ready to use. This raw data may also be used to provide logical linkage between transactions that somehow relate in a fundamental way.
“We can’t accommodate everything that comes down the pike. But we accommodate a lot and this is what we do to help future proof our product family,” concluded Baldwin.
