We continue our series on fintechs and how they improve payments and data handling flows.

One of the major trends that has emerged in the last five years is the “as-a-service” phenomenon. Payments as a service companies – true payment platforms for those offering payment capability as well as those needing to make and accept payments – are broadly available. Stripe is just one example. We are now seeing “banking as a service” providers proliferate.

We spoke with Robin Gandhi of TripActions in Episode 146. TripActions is a fintech focused on the travel needs and expense management of its enterprise customers. And what’s become clear from that conversation and many others is the extent to which fintechs serving specific vertical markets are able to focus so crisply because they can partner with these “as a service” providers who have done the hard, back office work of integration to banks, payments systems, and enterprise software.

We’re calling this trend “multiplayer fintech”. It enables firms like TripActions to take very comprehensive capabilities to market that no single provider could ever hope to do. And to, in a matter of months, deploy more efficient payment transaction flows through process redesign, modern user experience approaches, and with multiple revenue opportunities for the provider.

In this episode, we speak to one of the leading enablers and participants in multiplayer fintech, a company that has done the hard work of software enablement of payment operations, those challenging back office services. We are joined by Modern Treasury’s CEO Dimitri Dadiomov, its Chief Growth Officer Rachel Pike, and Erin McCune, Glenbrook’s B2B practice leader.

A True Fintech

One of the pleasures of producing Payments on Fire® is hearing the creation stories of fintechs like Modern Treasury. And, as with other firms, the business of Modern Treasury grew out of the tool set that Dmitri and his colleagues had to build in order to delivery the services of a mortgage industry firm they’d started. Integrating multiple financial institutions into their payments flow proved challenging given the number of banks and their typical reliance on legacy infrastructure. Speaking with other fintechs addressing other markets affirmed the breadth of those difficulties. Modern Treasury’s raison d’être was established.

In enterprise payments, payments operations is especially challenging. Nothing is as simple as tapping a card or writing a check. Challenges include payment initiation from inside the right application, approval management and controls, reconciliation, and reporting.

In classic fintech fashion, Modern Treasury has taken a design approach that starts with the user experience and process efficiency. No more automation of previously paper-based processes. This is about new replacement processes.

APIs Everywhere

Following the fintech playbook, Modern Treasury’s offer is based on an extensive set of APIs that support multiple payment methods including ACH, wires, check, the Real Time Payment (RTP) network, global payout capabilities, connection to the Canadian EFT system, and digital currency exchange specialist Silvergate Exchange Network, another fintech.

External account verification is supported via microdeposits and through a partnership with the fintech Plaid.

Synchronization of payment activity into accounting is made possible by connections into QuickBooks and NetSuite.

The multiplayer fintech theme is clear here, both in the build-out of Modern Treasury’s own operations as well as in its role as a payments operations platform for other providers.

So, listen to this episode. And, if you know how a particular industry works, dream of what you could assemble from building blocks like these.

George Peabody:
Welcome to Payments on Fire, a podcast from Glenbrook Partners about the payments industry, how it works, and trends in its evolution. I’m George Peabody, partner at Glenbrook and host of Payments on Fire. We are continuing our series on FinTechs and how they improve payments and data handling flows. And what are the major trends that have emerged in the last five years as a service phenomenon? We’ve heard of payments as a service and backing as a service, and what’s exciting to me is how broadly available this kind of capability is in place. For one example in the payments of services, you can think of Stripe, and for listeners, you may have heard Robin Gandhi of TripActions in episode 146 where TripActions is a FinTech focused on travel needs and expense management of its enterprise customers.

George Peabody:
And what’s become clear to me out of that conversation, and many others, is the extent to which FinTechs with a vertical focus have now got a palette of partners that could really bring these service-level tools to them. These are providers that have really done that hard back-office work of integrating directly to banks and to payments systems, and on the other hand, into enterprise software as well. So, there’s a real virtuous circle here of data, nevermind payments enablement, and we’re calling this trend multiplayer FinTech, where an outfit like TripActions can take and build very comprehensive capabilities to a particular market, something that no single provider could have ever done before, and they’ve been able to do it in a matter of months, as opposed to years or decades building out something that of course today is all entirely based on legacy code and is therefore inflexible web 1.0 or 2.0, and not optimize user experiences. So, I’m really excited to be joined today by someone who knows a whole lot about this space by my colleague, Erin McCune. Well, Erin, welcome. You’ve been on the show before, so glad to have you hear.

Erin McCune:
Glad to be here.

George Peabody:
Great. And today we’re speaking with one of the leading enablers and participants in this multiplayer FinTech world, a company that has done that hard work of software enabling those challenging back-office services. So, we’re joined by Modern Treasury, by its CEO Dimitri Dadiomov, and its chief growth officer Rachel Pike. Welcome to you both. Really glad to have you here.

Rachel Pike:
So nice to be here.

Dimitri Dadiomov:
Thanks for having us.

George Peabody:
So, let’s get started. Dimitri, Let’s dive in with what … well, actually, let’s get started, Dimitri, with … before we dive into Modern Treasury, I’d love to hear the creation story. How’d you get started with this business? It’s not a long story from what I understand.

Dimitri Dadiomov:
Yeah. Thank you. Thanks again for having us. It’s great to be here. We started the company in 2018, but the story really starts a few years before that. Sam, Matt, and I worked together at LendingHome, which is now the number one fix and flip mortgage lender in the U.S., and building a web-enabled mortgage lender in that case. And much of what we were spending our time working on was mortgage specific but, in some ways, even more of that was really much more around bank integrations and finance reconciliations and ops and customer service problems that were coming up as we were building this. So, we started observing some of these issues and just talking with our friends at other companies and realized that lots of companies had problems when it came to integrating the financial institutions and financial system into some sort of product flow. And so that really led us to starting Modern Treasury in the summer of 2018.

George Peabody:
Cool. So, take us forward now to 2021. What’s Modern Treasury doing? Who are you working with?

Dimitri Dadiomov:
Yeah. So, Modern Treasury builds payment operation software, and what that means is that we help companies that have money movement flows and their system manage payments across the life cycle of those payments. That includes initiating the payments, that includes managing approvals and controls, that includes all the way through to reconciliation and reporting. And when we think about different roles inside of those companies, everybody has a magic view that they want to be able to show up to work and be able to do their work and have software actually help them and not be a hindrance. So, that’s kind of how we think about these problems really from the user’s point of view and really thinking about the role that they’re in.

George Peabody:
What payments systems do you connect to?

Dimitri Dadiomov:
So, we connect to financial institutions that our clients work with. And so it really depends on a financial institution by financial institution level, but broadly speaking, it’s ACH, wire, paper check, RTP, things like that.

George Peabody:
That’s about all you need I think. Go ahead, Erin.

Erin McCune:
So, that’s all the non-card infrastructure. You’re sort of positioning yourselves as a complement to what we have observed as sort of the modern next-gen card issuing platforms, and they’ve sort of focused on that space and you’re dealing with all the other stuff, which as we’ve discussed before, is a lot of payment flows.

Rachel Pike:
Yeah, that’s right. So, there’s been a ton of wonderful innovation and wonderful companies built in the whole credit card stack top to bottom that you just alluded to, and we serve a lot of mutual customers, but all the bank-mediated bank-initiated payment rails that we just talked about, ACH, wire, check, RTP, that’s where we play and help companies out. By one of our recent calculations, it’s something like 75-76% of money movement in the U.S. is these rails, these bank-mediated rails.

Erin McCune:
So, what types of organizations are your customers and what types of use cases are they supporting that are more reliant on the non-card payment infrastructure?

Rachel Pike:
Yeah, all types. I mean, the main qualifier for a company that uses Modern Treasury and gets a lot of value from us is that in delivering their product, they move money. So, let’s go through a bunch of examples. An insurance company that collects premiums and pays out claims and manages a lot of liability in between, real estate companies that buy, sell, and rent homes or even issue mortgages, FinTech companies that are enabling all kinds of user behavior, but a good classic example would be investment into all kinds of things, payroll companies collecting money from a corporation and dispersing payroll and income to employees, marketplaces that collect money on one side and distribute to the sellers or the supply side of their market. So, it’s these really big chunks of the American economy, healthcare, insurance, education, financial services, where the types of money movement and payment operations that we support. That’s where most of our companies fall, our customers fall.

Erin McCune:
How do they find you? Are the banks that you are integrated with bringing you customers or are you bringing those banks customers or are the investors in some of these companies, if they’re newer entrance, advising them to work with you? How do they land on your doorstep or ring the bell on your doorstep?

Rachel Pike:
Yes. You’re right. Banks refer clients to us all the time and we refer clients to banks too, if they’re newer in their life cycle and they need a corporate banking relationship, or if they’re growing and they need a second corporate bank relationship. That’s another moment when we can really help. But I joined Dimitri and Matt and Sam in the early days to build this growth function. There’s like seven formal growth loops that we think about that are flywheels that turn our business and their traditional enterprise sales and marketing functions. So, there’s lots of different paths. Maybe some folks in your audience have read some of our content. We write a lot about payments and payment operations in payments infrastructure. We’re nerds about it. That’s one fun way that customers and prospects find us.

Erin McCune:
There are a lot of payment nerds out there.

Rachel Pike:
Yeah.

Erin McCune:
Tend to gravitate toward one another.

Rachel Pike:
We’re with you.

Erin McCune:
We get that quite a bit. Can I ask you a little bit about the nuts and bolts of what you’re doing? So, you’ve developed integrations into your bank partners, into the guts of the bank, the core systems as it were. How do you approach banks that you want to work with? Do they approach you? Do they sort of open the hood and you get the whole swath of infrastructure that they have to offer? How does that all work?

Dimitri Dadiomov:
It really depends. When we started the company, we really spent a lot of our summer in Y Combinator building our first integration with Silicon Valley Bank, which was the first bank that we supported. Since then, we’ve added a number of other banks, really driven by customer demand. So, for us, it all starts with a client need, and when we have a client in hand that we can approach a bank together, we can start the integration work over whatever rails the bank offers and prefers to offer for that particular client or for other clients. So, it really depends on how broad that might be based on the use cases that we are focused on.

Dimitri Dadiomov:
Of course, there is integration into the bank core systems, including balance and transaction reporting, things like high volume payments initiation that we have to go build on a per bank basis, and that’s sort of where it starts. But it’s just the start. And really after that, comes all the actual payment operations software that we think about a lot with more of us offering our own software piece, where we’re really stitching together all the flows through approvals and reconciliation and things like that, that are dependent on the particular financial institutions, but really are a lot more of the software that we’re focused on writing.

George Peabody:
Dimitri, how long does it take to actually do one of those integrations to the next new core?

Dimitri Dadiomov:
If it’s really a new core for us, we’ve built a lot of tooling around this, we have a lot of expertise in this, so it takes us days to weeks at this point for one we’ve seen before, and it takes us potentially weeks to a month or something like that for something that we may not have seen before, but that’s really something that, going back to the payments nerds comments, we have a lot of payments nerds on our engineering team that are excited to add new banks and excited to get into the differences between different ones. So, we think of that as something that is a bit of a core competence for us.

George Peabody:
And are you able to work with processors as well who are taking their cores to a lot of FIs or do you work with them directly or do you need to work directly with each of the banks? I mean, the processors, if they’re present, they got to be part of the equation.

Dimitri Dadiomov:
Yeah, absolutely. I mean, we always have to work directly with the banks because the banks are the ones who are ultimately serving our clients. So, we’ll take the bank’s cue on that, but absolutely. I mean, we work with whoever’s involved in making these banks run.

Rachel Pike:
And the banks all have different relationships with their own infrastructure providers, so sometimes they want us all included in one integration process and we do it together, and sometimes it’s really between us and the bank.

George Peabody:
Got it.

Erin McCune:
I’d like to go back to the value-add services that you’re adding on top. You’re providing obviously access to the bank infrastructure for your customers, but I’d love to hear you expand on the value add that you’re layering in on top of that in terms of the ongoing payments operation optimization. And I’m curious about the value for the bank as well as for the company that’s availing themselves of the account and payment infrastructure.

Rachel Pike:
Yeah. I think a good way to frame the value add question is to think about the chronology of a payment. Imagine $1 that has to move from here to there. The first step is payment initiation, which is where we are most deeply integrated with the bank, and that involves setting up a payment and all the tagging and tracking information that you want and getting that payment out. The next step is approving and releasing it, which is more of an operations team or a finance team process of control, and it’s sort of easy to imagine if you’re in a bank portal clicking release, but if you’re doing 10,000 payments a day, that’s a pretty big operational process that requires rule sets and permissioning, et cetera, layers and levels. So, we build a lot of software there. We have operations teams that spend many hours a day in our software managing high-volume payments.

Rachel Pike:
Then, there’s processing. Then, it comes back to us in the form of a balance and transactions report so we see that the money moved, and that’s where we do additional work in our software to automatically reconcile your payment to cash. And one of those confusing things that happens is payments get lumped together and batched out, and so tracking a payment all the way through can become really hard. So, we do this automatic reconciliation that’s really supportive and helpful for finance teams, whose job it is to track every dollar in a bank statement, and then we can ship all that data into your general ledger. Where a dollar lays to rest at the end of the day is general ledger for a company, and so our software covers that full life cycle and all those teams.

Rachel Pike:
So, you have the original team, might be a product or engineering team, that wants to move money at high volumes, you have a finance or operations team running the approvals and release, and you have reconciliation again, the finance team, and then you have the accounting team. You might even have customer service asking questions. “Did this money move?” Someone needs to answer a question of whether something happened and all that data is perfectly presentable for us. So, those are some examples of how the software serves the whole operation of a payment, as simple as that sounds.

Erin McCune:
You made it sound really simple. I know it’s not. I want to explore a little bit more. There are really visceral benefits to all of that orchestration in automating and streamlining and allowing various departments within your client company to really focus on where there’s a problem and the exceptions that require attention, as opposed to just the basic maintenance of making sure ticking in time, really, which doesn’t provide a lot of value add. What are the benefits for your bank partners in working with you to enrich, deepen relationships with new customers that they acquire as a result of their relationship with you, or customers they already have that may want to do some clever things that they couldn’t do without your support in conjunction with the bank’s core infrastructure? So, what’s the bank?

Rachel Pike:
Yeah. I’ll answer and I’ll pass it to Dimitri too. A couple of things. We allow banks to get new customers. So, a typical new bank integration would cost a company that hasn’t done it before, like six months and a full team at least. If they’ve never seen a bank core and they don’t think about this whole process, it’s a long arduous thing. And the bank is teaching and escorting them through that. We make it really easy. They can just sign up and write some API calls or sign up and click around. And so the bank gets to offer its services to a wider group of customers or to speed up that customer onboarding experience. Then, the second thing, which is maybe further in the funnel, is those are really deep corporate banking relationships. If you’re running transactional processes on a bank, that’s really fabulous for the bank because now the bank gets to sell other parts of the relationship that we don’t touch because it’s very core to this company’s work.

Rachel Pike:
So, those are two places where we really help the bank. Dimitri, any other ideas?

Dimitri Dadiomov:
Yeah, I think I would just add really that one of the beautiful things about this new API-driven economy if you will, is that it’s really built around jobs to be done and the job to be done for a company like LendingHome was to disperse mortgages, to take in investments, to collect those payments, to disperse them back to the investors who owned those. It was not to understand what ACHR 15 was for the return. It was not to go chasing how many outstanding paper checks have been in the mail and have not been cashed yet. All those things that are really not core to the company’s business really help get the company up and running quickly, but it also helps the bank provide better service because the conversations between the banks and the clients are much more strategic, they’re much more interesting.

Dimitri Dadiomov:
There’s a lot less friction. So, from a customer service perspective, I assume the NPS scores are probably higher for clients who use Modern Treasury versus some of the ones who’ve really focused on building things internally and have to see each new return one-off and that kicks off a whole week-long chain of investigation. So, I think that really, at the end of the day, the beautiful thing about software is that it takes care of these problems and the ironic thing is that this is the stuff that computers are supposed to be good at, and a lot of legacy systems get in the way of people actually running their businesses. So, I think the job to be done aspect of API is really powerful.

Erin McCune:
And it must be on some level … I guess it would depend on who you spoke with at the bank. There are product managers within some of these big treasury banks that are awfully proud of their integration capabilities and their reporting capabilities, which wouldn’t really be necessary if someone was connecting in through Modern Treasury. But at the same time, connecting in through you is allowing high volume flow of transactions at very little effort on behalf of the banks. It depends on who you talk to at the bank.

Dimitri Dadiomov:
I think that’s right. But to be honest, in some cases, we’re best friends with some of those product managers focused on this because we have now at this point, probably integrated with more banks and more cores than any other company, because why would any other company integrate with a new core? It just makes no sense. You might have three or four banking relationships, but you probably don’t have 15 bank relationships in the U.S. So, some of the conversations that we’ve been in with people in those roles when Sam Aarons, our CTO, gets involved are some of the richest conversations that we’ve had because they really understand the systems. So, we think that we’re hopefully elevating the conversations and getting beyond that first couple of months, somebody’s just learning what the ACH system even is, trying to build the basic product for it, and getting into the more interesting questions.

Erin McCune:
Can we delve into some of the payment flows? And we’ve been talking recently here at Glenbrook about … I don’t know how to phrase it. A resurgence, that’s not the right way to characterize it. I think the way we’ve been jokingly saying it, and now I’m going to say it publicly and feel embarrassed, we’ve been talking about ACH is all of a sudden hot. Everyone wants to talk about ACH, which is sort of funny because ACH has been around since the seventies, but there’s this moment for ACH right now, and I feel like you are really in the mix on that and in a variety of different ways.

Erin McCune:
So, I’d love to hear you talk a little bit about ACH, but then I’d also like to segue from there to talk a little bit about same-day ACH and where that’s been applicable and then real-time payments and on that spectrum of transactions. We can go all the way to wires. Let’s talk a little bit about what type of payment makes sense in what circumstance and how you help your constituents, both the banks and your customers, that are moving money as part of their business model, make the right choices about which rail.

Dimitri Dadiomov:
Yeah. Maybe I can start and pass it off to Rachel. Really, one of the reasons why I think ACH is so relevant all of a sudden, this is something that has dawned on us over the past year or two, as we’ve started engaging with a lot more of these clients that are coming to us, is that if you think about the internet 15 years ago, e-commerce was really the primary commercial engagement on the internet. And so really, the question was how do you accept payments over the web? How do you accept a credit card payment for Amazon book buying or something around travel or subscriptions? And those were really the core problems of the internet when it comes to commerce and payments.

Dimitri Dadiomov:
And over the past five years or so, we’ve started seeing a lot more companies. I think LendingHome was a very early entrant into this, but the problems that we had in the real estate world around ACH and wire were just not problems that internet-specific companies had to deal with. So, I think maybe one very macro way to explain why ACH is relevant again is because the internet is starting to mess with real estate and healthcare and insurance and education and all these things that we really care about in society, but companies, internet companies, web companies were not able to reach that or did not have the financing, or I don’t quite know exactly what it is that led to this. But all of a sudden, we’re having a lot more companies that are buying and selling homes and managing student loans and doing all kinds of things that really were not part of the web economy.

Dimitri Dadiomov:
So, when these companies get into that, and this was our experience with LendingHome, you get up close to the ACH, wire, paper check world because credit cards don’t really have a place in funding a home or something like that. So, that’d be my answer to why ACH is relevant again. But, we definitely agree that it’s become a topic of conversation and hopefully, some of our posts are helping answer some of the questions that are coming up, but it is definitely more of a relevant topic.

Rachel Pike:
Erin, I’m going to answer the second part of your question, which is how do we coach people to make decisions about which rail. So, here they are mucking about with healthcare, insurance, education, real estate. Sometimes it’s obvious because there’s a cultural history of homes are bought with wires and they’re entering the market and they want to play the same game that’s been played and that doesn’t require a lot of coaching. But, in moments when one of our customers is making that design decision, there’s four attributes I can think of. Maybe this group can be smarter and add five or six, but there’s four I can think of.

Rachel Pike:
The first is cost. So, the underlying transaction cost that the bank charges varies between wire, ACH, same-day ACH, and RTP, and sometimes cost really matters in a particular flow, and sometimes it doesn’t. So, that’s one decision point, one criteria. The second is revocability or reversibility. Wires and RTP, they go, they go. That’s why we buy homes that way in escrow. And ACH is reversible. You can return a payment. And depending on the payment flow, that can be a very valuable attribute or a very risky attribute that we want to avoid. It just really depends on what they’re designing for.

Rachel Pike:
The third is really obvious, which is speed. ACH moves the slowest, then same-day ACH, then wires and RTP. And there are a lot of interesting conversations right now about people trying to create more delightful payments experiences through speed. So, maybe when we get to RTP, we’ll talk about some of those. And then the last we actually encounter the most confusion on which is direction. You can only debit over the ACH rails. And we actually do a lot of coaching and education about RTP not being a debit rail. That’s not a construct. So, it depends which direction the money needs to move and what the constituent product is they’re building for, and then we use those criteria to help them make a decision.

Erin McCune:
I’m going to ask about RTP. My sense is that you’ve been doing quite a bit. RTP is relatively new. You’ve been doing quite a bit to enable new transactions on the new real-time infrastructure. We spend a lot of time talking about who needs that and why. I’d be curious to know your perspectives.

Rachel Pike:
Sure. I’m going to answer-

Erin McCune:
On those attributes, what type of use cases are you seeing the most adoption of RTP?

Rachel Pike:
We are seeing businesses adopt it at the parts of their business that touch consumers because that’s where it can create the most delight. So, in real estate, we’re not seeing folks mess with the insurance portion of the transaction, but the part where you pay an individual agent or you pay out an individual, a home seller, that creates real delight if it hits your bank account right in the moment. Or in payroll, of course, receiving your money every day, or with instant speed instead of a three-day hold is a huge user satisfaction increase. So, that’s where we see businesses gravitating towards first.

George Peabody:
Rachel, I’m wondering if you are seeing any traction for ISO 20.022 inside of RTP.

Rachel Pike:
Oh, my God. We write about it a lot because we can’t wait for it, but no, we haven’t seen anyone do request for pay yet. It’s like this magical thing we really want to happen. Probably all four of us.

Erin McCune:
I know. Exactly. We’ve talked about that. I think the request to pay is the secret to getting rid of small business checks, but that’s another podcast for another day.

Rachel Pike:
Yeah. Big sigh.

George Peabody:
So, let me wrap up with a last question, which is, have you found any use cases that have startled you, or just delighted you, that you’ve seen what your software in action, doing things that were hitherto sort of unimaginable?

Dimitri Dadiomov:
One way that I really think about customer delight is we have companies that went live with Modern Treasury, and they have built significant businesses. They are 150, 200, 300 people now where they started as like a three- or four-person company and everything. And their system just runs through Modern Treasury. They don’t know the pain that they avoided. We have to remind them sometimes, but it’s a great thing to see where certain teams that are logging in every day or every week, they have certain teams that build the API one time and forgot about it and really only have to pick it up and come back and fix something when their business model changes or they’re entering a new state or a new product or something that they’re offering.

Dimitri Dadiomov:
But really, it’s just part of the stitching of how their business works. And I think that as we help companies move money with confidence and really have software be the guardrails and make sure that your business is just smoothly run and well-run, and everything is continuously accounted for, that’s a really cool thing to see because those companies also we hope do better because they’re focused on the things that really move the needle for their customers, not the back-office.

George Peabody:
Got it. Great.

Erin McCune:
Poor back office. Nobody wants to think about it.

Rachel Pike:
That’s why we build software for them. I mean, I would agree with Dimitri. The great joy is seeing companies large and small grow so fast because they don’t have to think about what we do if we just take it all away and the computers do it. And that’s how it should be. And there’s companies that have grown a lot. There are big companies that have launched new products that have grown a lot and, on the inside, that’s just a great joy to support that.

George Peabody:
Well, thank you, all three of you very much. Really appreciate you being on Payments on Fire. And I have a feeling we’re going to be reconvening this pack of payment nerds before very long.

Erin McCune:
Maybe even in person.

George Peabody:
Oh, that’d be great.

Rachel Pike:
See you there.

Erin McCune:
Wouldn’t that be great?

Dimitri Dadiomov:
Any time.

Rachel Pike:
Yeah.

Erin McCune:
Enjoy your weekend.