Building Resilient Payment Operations

Given the recent bank failures, the importance of a financial operating system that is able to withstand unexpected disruptions and adapt to new challenges has never been clearer. We know that for many companies, how to better-build resilience into their payment systems is top-of-mind. Yesterday, we hosted a panel discussion addressing just that, including how to go about future-proofing payments systems with a multi-bank strategy from day one.

Moderated by Molly Fischer, our Head of Enterprise Sales, our panel included Sam Aarons, Co-Founder and Chief Technology Officer; Matt Marcus, Co-Founder and Chief Product Officer; and Nick Farrow, Head of Bank Partnerships. Below, we’ll look at some of the key takeaways from our discussion. Plus, we’ll review a few of the questions answered in our Q&A session.

Key Takeaways:

A Multi-Bank Strategy for Your Payments Platform is Imperative

When it comes to companies that need to move money through a bank to operate their product or provide their service, the idea of banking resiliency is especially important. It’s rare that one bank can work well for any business. In terms of the bank failures we’ve witnessed over the last few weeks, there were businesses that we spoke to that were faced with wondering, “Am I going to lose all of my money?”

Even outside of failures, banks can and do run into issues that can be problematic for businesses that don’t have backup solutions in place to move funds.  Still, you don’t want to over-index on banking partners and have too many—you need to be able to maintain strong, positive relationships across all of your banks.

Thinking about bank resiliency in context, then, we can break it down into a few basic ideas:

• Is my company’s money and/or the money I hold on behalf of my customers safe? Can I move my money quickly if I need to?
• What banks am I using to provide my core product or service?  Which banks am I using for my core payments? Are my bank(s) reliable?
• How can I think about building more resiliency into my banking relationships? How strong are my banking relationships?
• Do I have fallback options in the event of an emergency? Can I fallback on ACH if RTP is not available, for example?

When thinking about banking relationships, it is important to keep in mind that you’ll probably need a number of different banks to perform the various payments functions that your company needs to provide your products and services. Businesses should ensure that they have at least one backup (if not more) for their banks and service providers, so that in the event of an emergency, essential functions can still be performed through load balances or payment shifts across those backup options.

If you need operational consistency, you need multiple banks.

One thing we often tell customers is that, while many banks have similarities, all banks are, technically, different and have their own technical idiosyncrasies. This applies to even the simplest things, like how to connect to banks in the first place: some banks have SFTP, or file-based, integrations while others have APIs, and some use both.

Simply integrating with multiple banks means dealing with multiple technologies that you need to know and implement, which can be challenging. Plus, all banks have slightly different ways that they go about reporting transactions and balances, how they send transactions, and how they handle the varying standards across all the different payment rails.

At its core, every bank runs its own technology stack, so you’re bound to see differences between all of them. But there are enough commonalities at a high level, that you can use an operating system like Modern Treasury to help bridge that gap and standardize and streamline the ability to talk to multiple banks.

Resilient payment operations are something that you need every day, not just for once-every-ten-year events. There are lots of reasons to use multiple banks, primarily to survive operational burdens—banks consistently have minor issues like delayed reporting or maintenance that requires turning off their API for a day. Having software that is  able to talk to multiple banks at the same time to scale payment functionality and fail over transparently is key.

Onboard the Right Way, With the Right Bank Partners.

When onboarding with a bank, approach it as building a relationship and a partnership with your bank. Depending on how your business moves money, it can be difficult for a bank to understand what your business does and the risk associated with being your bank. It’s imperative to be able to tell a clear story around the types of risk you face with your business, the tools and people you have to manage those risks, and to show evidence of the policies and procedures you use when your business is faced with risk. Ultimately, you want your bank to understand and know your business and have a strong relationship with your team, so that they can advocate for you when you need them.

Bankers want to help their customers, but they also have to weigh the operational risks for their bank that comes with working with any business. As you move through the onboarding process, having all your materials already ready to go (ACH return rates, compliance program documents, etc.) will make the onboarding process faster and easier.

Especially now, many banks are inundated with new customer requests and coming prepared for onboarding can streamline the process on all sides.

When onboarding with a new bank, there are a few key questions to consider:

• Is the money I hold and hold on behalf of my customers safe with my bank? Can I move my money quickly if I need to? Can I rely on ACH and the other payments services provided by my bank?
• How do I ensure this is a true partnership? Am I sure that my team can successfully manage this banking relationship?
• Is this bank well-suited to my business model? Do I feel confident that my banker would advocate for my business in a time of need?

Not every bank is going to be the right fit for every business, so it is important to understand which banks will work well for your business model. If you need assistance finding the right bank to work with for your business, we’d be happy to help.

Best Practices For Building Reliable Payment Infrastructure.

When we set up our status pages tracking payment health during the bank failures, what really enabled us to stand up those pages was all the telemetry that we’ve built to keep track of how systems are working. We set this up so we can identify issues and proactively address them either programmatically or with human intervention.

We consider what our customers need: Do they have a robust payment system that is 24/7/365? If that system fails at 3am on a Sunday, do payments get retried? Are they alerted immediately? How do they alert their customers?

Those aren’t trivial tasks, they’re imperative, time-sensitive business functions.

Historically, when thinking about product roadmap and efficiency and managing risk, we’ve seen a lot of companies opt for a single-bank path. Because they have a product to build and other things to focus on, initially, the risk of a single-bank path might not seem that substantial. But we’ve also had discussions with a lot of customers that were affected by the recent bank failures that regret the decision to not invest in a multi-bank strategy early on.

For businesses where payments are critical to the way their product or service works, it's imperative to have a second bank or a second way to process payments from the very start. Part of that is doing some risk calculation when setting up your banking partnerships. You have to think about how robust your bank partners really are, and whether or not, in the case of another black swan event, you’re confident in their ability to handle that situation. For a lot of companies, not being able to operate in terms of payments is existential—so having a failover plan means business continuity and business health.

Q&A:

Attendees of the webinar asked some insightful questions during our Q&A session. Included below is a sampling of some of the questions that our panelists answered.

Q: How could Modern Treasury have helped me avoid the issues we all faced two weeks ago?

A: Modern Treasury’s focus as a software operating system is to allow customers to manage the full cycle of their money movement. We work closely with our customers and banking partners—and we help keep those relationships healthy. In the case of a bank failure, customers who are using Modern Treasury with multiple banks, swapping banks can be as easy as having engineers do a one line code change.

We’ve also been heavily investing in helping our customers find new and additional banking partners; guiding them through the bank onboarding process and helping them navigate banking relationships, if that isn’t a core competency for their business.

Q: What if I bank with a GSIB, do I need redundancy?

A: If you’re banking with a global systemically important bank (GSIB), the risk of a bank failure does go down dramatically. But that really isn’t the type of day-to-day risk that most businesses need to be worried about. GSIBs and small banks alike all run into operational issues and maintenance, which impact payments. That doesn’t mean that you need to have banking relationships with 6+ banks, but you do want to have at least two banking relationships to be ready to deal with operational issues, big and small.

Q: With a multi-bank strategy and the transactional nature of banks, do you have any advice to offer on how to manage a primary/failover configuration? Would you advise spitting volume to keep the failover bank engaged?

A: This will depend on your relationship with your bank. Most companies only have the bandwidth to manage a primary and a secondary banking relationship, so you don’t necessarily have to have a 50/50 split.

Having 80% of volume in a single bank and a single banking relationship and then 20% somewhere else is a good strategy, in a lot of cases. A secondary bank, in the event of an operational burden, is key: you have money there and have tested payments, so you can switch over quickly.

But it also depends on the complexity of what you’re doing with your business. If you’re just processing ACH payouts, for example, that is pretty easy to run through multiple banks or payment providers simultaneously. If you have a more complex payments stack—an FBO account with virtual accounts where you’re subledgering user balances, for example—we would probably recommend pushing that through one bank, because it can be much harder to manage that level of complexity across multiple banks.

Q: How do you see FedNow evolving the banking ecosystem in the US ?

A:  We believe that FedNow will be a sea change for payments in the US, and that FedNow will be adopted quickly once it's available. In the US we tend to have two systems—public and private—for every payment option that's available. For 24/7 instant payments we only have RTP, which is the private option. FedNow is going to be the public option. And when it launches it'll be simple for a lot of payments to start happening 24/7/365, which is a huge change from where we are at today. Right now, ACH clears overnight and wires are quick, but don’t process during weekends or evenings.

Look at the UK with the FPS, China with wallet systems, and Singapore and Australia with their instant payment systems—consumers are able to pay each other quickly, businesses are able to pay each other quickly, and we’re going to see that happen in the US, too. FedNow will change consumer expectations, too. Consumers will be asking, “Why am I waiting for a check in the mail? Why am I waiting overnight for my money to clear?” and that will precipitate other changes as well.

Q: In your estimation, how will the quickening of transactions impact fraud controls?

A: Consumer expectation is already there that RTP payments happen within 10 seconds, meaning those fraud checks need to be that fast, too. You will need compliance systems that work instantly on these payments: consumers don’t want to wait an hour for their money, that is why they use RTP or instant payments in the first place. Credit cards, for example, already do real-time fraud checks on card swipes or authorizations. It’s just a matter of reorienting your fraud control systems to no longer be batch systems and writing automated code for this type of thing. Humans can’t approve an RTP payment in ten seconds, so that is an industry change you can expect to come with these instant payments, too.

Watch a recording of the complete webinar and Q&A, here.