How Does Treasury Prime’s Banking API Integration Compare with Other BaaS Companies?

Treasury Prime’s modern banking API integration is optimized for observability, stability, security, and compliance, and allows companies to launch embedded finance products in as little as two weeks. What makes us unique, though, goes beyond how our API works — it comes down to how we work with developers.

We talk with Treasury Prime Director of Developer Relations Kyle Tyacke about what you can expect when working with Treasury Prime’s tools. He explained how Treasury Prime ensures its banking as a service (BaaS) platform is easy to use, and what goes on in the background to ensure flexibility and success for our fintech and embedded finance partners. 

How easy is it to implement Treasury Prime’s banking API integration?

We use a modern RESTful interface that should be familiar to developers from across different product backgrounds. That doesn’t really differentiate Treasury Prime from other software tools — whether we’re talking fintech or other industries — and that’s kind of the point. 

When it comes to Treasury Prime’s banking API, developers should expect to encounter what they’re accustomed to seeing. As far as what makes Treasury Prime unique, that really comes down to what developers don’t have to worry about. We have applied our team’s collective decades of banking experience to simplify the experience of developing tools that incorporate banking products. The result is that developers using the Treasury Prime platform get to focus on what they do best: creating high-quality applications. 

What can Treasury Prime do that other BaaS providers can’t?

The big differentiator with our business is that we partner with multiple banks. We work with roughly a dozen now, and we’re constantly scaling across new bank partners. That means it’s easier for a fintech to find the right bank for their needs. It also means that if their needs change, or if they need to expand beyond their initial bank, our platform will let them change banks or add a new bank without having to integrate with a new API or fundamentally change how they operate their product. 

BaaS & embedded banking options

Let’s say a fintech or company that embeds banking wants to do deposits totaling $10 billion, and the bank partner that they're working with can only support capacity for $1 billion. They might need to go out to multiple banks to reach that capacity. If they work with a BaaS provider that has only one bank partner — which is often the case with other providers — then they may have to find a secondary BaaS provider to reach other banks. If they work with Treasury Prime, they can stay in the same system and just add another bank or multiple banks. Similarly, if a fintech needs to change banks, they can do that as well. So for example, if your fintech works with cannabis, and a regulatory change causes your original bank to pull back, Treasury Prime will let you transfer over your accounts to a new bank with a lot less hassle. Our partnership with leading banking core provider FIS makes adding or changing banks even faster and easier. 

The business benefits to this flexibility are pretty apparent, but this setup also makes things a lot easier for developers. Because we normalize our API across our bank partners, the development required to work with one bank should work largely the same at the next. That means no arduous rip and replace process if you need to switch banks or add a new bank partner. While changing your bank partner setup will of course involve some configuration, developers won’t have to spend countless hours redeveloping their entire application to work with a new API.

This flexibility looks different, but still holds, whether you opt for on-core or FBO account options. In either case, you are working with the same, always up-to-date Treasury Prime API with any bank partner in our network. 

Developers can learn more about our process by exploring our API reference or playing around with our Developer Sandbox.

The difference between opting for the on-core versus FBO account approach?

If you go the on-core route, that means you are opening customer accounts directly on the bank’s core. This approach can be more hands-off because you can rely heavily on your bank partner to oversee regulatory and fraud prevention requirements. If you’re embedding peripheral financial tools on your non-financial app, on-core accounts may be less labor intensive. An FBO or “for benefit of” account refers to an umbrella account that you, the business, open on the bank’s core, from which you can issue multiple virtual accounts for your users. This second option tends to offer more flexibility and control, and is well-suited to apps that center around banking and finance. 

Critically, when you go the FBO route with Treasury Prime, your fintech gets its own FBO account. That means you get full control over your user’s entire experience, as well as control over your KYC and compliance setup. This is different from some other BaaS providers, which pool all their fintech partners into one massive FBO account. The problem with this pooling approach is that it results in fintechs sharing risk, and forces them into using a one-size-fits-all KYC and compliance approach 

How does Treasury Prime’s architecture make this flexibility possible?

Our architecture is a bit different from other BaaS providers. We simplify things as much as possible by automating a lot of the more difficult aspects of complex tasks. Account opening, for example, may seem complex if you look at our API, which shows several steps; but a lot of those steps are automated so developers only have to worry about the process at a high level. Other times, Treasury Prime is actually handling real-world banking operations on your behalf. So while on your side, a task may look like a simple API call, on our end, it requires interfacing with the financial system.

Let’s look at an ACH transfer as an example. A developer just sees a basic protocol for sending money from one account to another over ACH, but behind the scenes, the process is more complex. Treasury Prime is taking that transfer, we're populating it into a file, we're sending that to a bank, the bank sends it to the Federal Reserve, the Federal Reserve clears it and sends it on to the receiving bank, and finally the receiving bank processes the funds and deposits them into the recipient’s account. 

This normalization, this effort to simplify the developer experience, is really important when you consider the varied industry experiences of developers. We see a lot of the developers in our space coming from other technical backgrounds. They might not be familiar with banks at all. So simplifying different features or processes like account opening or sending funds through ACH, and normalizing experience across bank partners, together make our tools highly approachable. 

Where you’ll see an even bigger difference is when it comes to integrating with banks. We work really hard at normalizing the fintech experience across bank cores. So whether our API is integrating with one bank or another, it’s going to look the same for fintech developers. When we add a new bank partner to Treasury Prime’s network, we do the hard work of meeting their unique requirements on our end, so the experience feels predictable and smooth for fintechs on the other end. We also integrate directly with each bank’s core, which enables us to offer more real time capabilities, like real-time reconciliation. 

What is real-time reconciliation and why does it matter?

A lot of our competitors do what’s called an “end of day settlement.” So what they'll do is, throughout the day, they'll have a bunch of transactions happening, and they will be logging them to their ledger, which is their balance of their accounts. Then at the end of the day, they just do one batch settlement. They do it this way because it’s easier. Integrating with a bank’s core is extremely difficult, so they skip this step.

Treasury Prime is unique because we do the hard work of integrating with bank cores directly, and this allows us to reconcile transactions as they happen. This is called “real-time reconciliation.” So throughout the day, as transactions are occurring, we’re simultaneously making requests to the bank’s core to update the movement of funds.

Real-time reconciliation translates to real-time access to bank systems, which in turn supports features that otherwise would not be possible. One such feature is Treasury Prime’s “reserve sweep” option, which enables fintechs to allow customers to spend more than the available funds in their account. There are a few different ways fintechs can use this feature: You might enable overdraft protection; you might enable early access to direct deposit; or you might allow users to spend cash that is still in the process of being deposited. It’s up to you. And that’s just one example of what real-time reconciliation makes possible. The big picture is that, because we reconcile accounts in real time, we can give you full access to your bank’s capabilities. 

How does Treasury Prime work with developers?

We take a very hands-on approach to support. This starts at implementation, but we continue to work closely with developers and to individualize our approach with them as they continue to use our product. Every team that we encounter is a little bit different. Some are very knowledgeable about both banking and software, while others are new to one or both areas. We have clients who are new to development in general. I've worked with some developers with our clients who are in their first or second gig, they may have not really worked with APIs before, so they need a lot of information and explaining around how requests and responses work and what that means in a banking environment. 

A big thing that’s different about building a fintech compared to building another type of tech company is you have to work around this big, complicated banking system. Developers are accustomed to things working instantaneously. With most APIs, you expect immediate results. But when you’re engaging with banking, things work differently. So while our tools are easy to use, we still are beholden to the rules and regulations of banking. We have to work within the requirements of the banking system. So for things like money movement, it's a big thing. An ACH transfer might take three days to settle, unless you pay the bank extra to expedite it, because that’s how long banks and the Federal Reserve need to process a payment along that payment rail. 

The investment in guiding clients through these things, while also providing a super navigable development environment, is something that really sets us apart. We have sharp, fast, clean, and well-integrated tools, and we also have a team that really understands where you’re coming from and that can support you while you’re leveraging our API to build your product. 

Want to learn more about how to evaluate banking APIs? Treasury Prime is happy to answer your questions directly. Contact us here. Read more about our API banking solutions.