Real-Time Reconciliation: A Chat with Wayne Lin and Sean Bolton

Cash reconciliation is a challenge for most companies, and it is especially challenging for companies moving money within products.

To reconcile transactions, many companies rely upon manual operations and disparate tools, which can be fragile and difficult to maintain, and can limit their understanding regarding financial activity. This can lead to disjointed products and limited information available for financial decisions.

Modern Treasury recently launched a Reconciliation Engine to help companies track and attribute their payments in real time.

In a recent Tech Talk, Modern Treasury’s Reconciliation Engine Product Manager, Wayne Lin, and Senior Software Engineer, Sean Bolton, discussed reconciliation at scale and shared insights and learnings useful to any business.

The following is an excerpt of the discussion, which has been edited for clarity.

Q: How did the reconciliation engine at Modern Treasury originate?

Sean: Modern Treasury started around the problem of payment origination. We wanted to facilitate payments on behalf of customers. We needed a check mark on our side to know that a payment was successfully completed versus just sending a payment into the black hole of the banking system.

Without reconciliation, no one knows if a payment succeeded or not. We realized reconciliation was a central piece for us to know that our work for customers was solid, and that good reconciliation applied to businesses of all kinds, even if not originating payments.

Wayne: It all goes back to having a full life cycle of a payment’s status. What we're doing is taking all of the secret sauce of what's made our reconciliation engine great for monetary repayments, and saying, “If you don't send payment instructions to us, we still want to help you solve the reconciliation problem because we know how painful it is. And we have a lot of great tools and learnings we’d  like to share about how to do that”.

Q: “Reconciliation” can mean several things. Can you break down the term?

Wayne: There are different flavors. There are those where you compare two different data sources, your bank and your internal record, for instance. You want to make sure those two things match up. There could also be three-way reconciliation, say a credit card to a bank and to the internal record. There could be non-cash reconciliation, for instance, if you ran a loyalty system, or non-bank reconciliation, like with credit card processors, etc. The point is to make them all automated so payments get tracked start to finish as fast as possible.

Q: What happens when reconciliation doesn’t happen, or if it happens inaccurately or slowly?

Q: In technical terms, why is reconciliation so hard?

Sean: The complexity of the banking system explains a lot of it. Systems vary per bank, per payment rail, even per the different software solutions that banks use. Batching is one of the biggest complexities. Banks batch payments together so you might send 10 payments but it’ll show up as single transactions in your statement.

In one instance, we worked with a bank that stopped batching during the lunch hour, which meant the statement was was never consistent and varied  based on when lunch occurred or who was working.

In smaller companies, humans can spot such things and know what is going on and know that 10 payments got batched into two transactions. But when companies get bigger, humans cannot solve for that and software and automation has to come into play.

Companies basically have no control over the bank system that is producing data regarding the movement of dollars, and reconciliation is about making sense of data to make sure it follows the dollars.

You have to deal with data ingestion from banks, validating the data and then running it through normalization. Overall, you need a system that is robust.

Q: How can a good reconciliation system help manage customer risk and liability?

Wayne: Money moves in and out of bank accounts constantly for many companies. You reduce risk and liability by shortening the time between when a payment was made and when you know about it. Automation shortens such gaps.

Sean: Look at the ACH system, for example. It has defined windows when you can reconcile an action and dishonor a payment return, for instance. The faster you can get to a reconciled state the better. A lot of businesses have three-plus days of lag time. If you can figure out automatic reconciliation, you can also see signals, like intraday reporting from banks, saying, “Hey, this money will settle tomorrow.”

And you can build that knowledge into your risk profile and maybe take advantage of that signal. If you use multiple banks, it gets even more complicated to know your risk profile, to get to a single source of truth, and to manage it. Good reconciliation reduces those kinds of risks.

Q: What changes do we see around the launch of FedNow, and what implications does that have for reconciliation?

Sean: We’ve thought about this a lot and it has huge implications. Immediate settlement rails highlight the need for real-time, always-on reconciliation. FedNow and RTP, these rails happen 24/7 and payments happen instantly in contrast to ACH, which can take two days and doesn’t operate on weekends. If you have manual reconciliation flows and more real-time payments, you’ll have to think about: are we going to staff reconciliation on weekends, or at night?

Wayne: The pace of reconciliation needs to keep up with the speed of payments. That’s why we believe that payments will eventually begin and end in software and the end is the reconciliation piece.

Q: How unique should reconciliation rules be at different businesses?

Wayne: They can be very different by bank and company, and even by product if you offer different payment rails. Each of those product streams might support different types of payment flows. Maybe some are one to one, some are batched, some are split payments like with installments.

Your reconciliation rules need to adapt to all those different types. But let's say, you also allow different payment rails. Sometimes you offer real-time payments, sometimes credit cards. Now you have to multiply the products by the number of rails and then by the number of banks.

So you can see how the reconciliation rules quickly balloon. At the end of the day, we see a ton of different reconciliation rules that need to be put in place to make sure automation can actually happen.

Q: What is end-to-end reconciliation? What should companies think about if they want to build it?

Sean: Reconciliation is a multi-step process. We see basically five pillars. The first is to get good data into your system. That will likely come from your bank but it could also come from places like your ERP system. Then you have to normalize and enrich the data. The reconciliation engine, then, takes these transactions and matches them to business, either payments you originated via invoices, or things like that.

Even the best matching system in the world will have to handle exceptions. Our matching engine is designed to only make a match if it is 100% confident that it is the right one. Mis-reconciling causes a lot of chaos downstream. So your system should be designed with an exception handling process that probably should have some manual review. Finally, you end up in a state where everything is reconciled. and you can then export that data downstream and post to your ledger.

Q: How will AI impact end to end reconciliation?

Wayne: What is really important in terms of end to end reconciliation is automation and accuracy. At each of these stages, you can leverage AI or machine learning to make sure that you're achieving high automation without sacrificing accuracy.

For example, let's say you are in real estate and addresses are really important for your reconciliation workflow because you receive transactions or payments relating to specific addresses.

Humans know that an address like 1 S. Main is the same as 1 South Main. The question here is, how do you leverage data, models or data modeling techniques, to make sure that ]the computer sees that this is actually the same thing. Ultimately, what we're trying to do is make software do what humans actually do, and to do it at scale, because that's where software can help.

Sean: We want to make the job of the manual reviewer super efficient, That is what we’re looking for.

Q: If you're a PM or engineer designing a reconciliation system for scale, what are the top pieces of advice?

Sean: If you are building for scale, build everything for the full flow. If you only build part of this, you will have bottlenecks. Consider the whole system, not just the pieces.

This means you have to give everything a lot of thought. Your data ingestion has to be quick, make sure the matching engine can handle the scale, that it's accurate enough to not throw off too many exceptions and so on.

Exception handling, for instance, should not be an afterthought. Don’t assume your system will work all the time. That’s always the goal, but it won’t work because you don’t control the network or the bank that you’re working with. You could face changes in how software is updated, how transactions are batched, how descriptions are set. Exception handling should be first class when it comes to your considerations.

Wayne: Anticipate complexity, chaos. Don’t anticipate simplicity.  If you go into the system assuming that most reconciliations will be one to one, it’s going to cause problems. If you anticipate complexity, you will think about the problem in a different way.

Apply that thinking to the five pieces of work: data ingestion, normalization, enrichment, matching, exporting. Do it end to end. But start somewhere. Don’t wait until things are breaking down and your company cannot close in a month, and throwing people at the problem won’t help. Get the systems in place before things start to break.

Sean: Even if you pick a subset of the problem you’re trying to solve, that will force you to build the whole flow and it builds up a bit of knowledge on how to go about reconciling the next challenge, maybe wires, or adding a new bank. You’re not starting from scratch each time. You're building on that knowledge and building on the systems you've built.

Next Steps

Modern Treasury enables companies to automate payments from end-to-end, including reconciliation, payment orchestration, compliance and ledgering. If you are interested in learning more, reach out to us.