How BaaS Provider Treasury Prime Builds its Open Banking API Solutions

Observability, stability, security & more—What fintech developers need to know
Mike Clarke Headshot
Mike Clarke
Vice President of Engineering
January 27, 2022
Treasury Prime branding in front of code pane showing Bill Pay capability

Treasury Prime has been an engineering-first embedded finance organization since its founding by CEO Chris Dean and President Jim Brusstar — who are both from technical backgrounds. That gives us special insight into the concerns and priorities of developers. 

We know how challenging it is to find an open banking API partner you can trust as much as the work from your own team. Our response is to be as transparent as possible about how we work, so that developers know exactly what they are getting into when they start using our banking as a service (BaaS) platform. 

When it comes to building a fintech startup or embedding banking financial services in a non-fintech app, you need a BaaS partner you can depend on to successfully integrate with financial institutions. 

One thing that makes Treasury Prime unique is our equal focus on both fintechs and banks. We don’t just digitize banking or provide open banking API solutions to fintechs, but we act as an intermediary between two very different markets that need to work together to achieve mutual success.

We offer the fastest and most supported experience for fintechs, with usage-based pricing that guarantees all parties succeed only if your business succeeds. We also offer the best economics for banks, which helps attract best-in-business chartered bank partners to support your fintech. Our banking partners include Grasshopper Bank, LendingClub Bank, Burling Bank, Piermont Bank, and more.

Here are five key aspects of how our online banking API works. To learn more about what to look for in a banking API, read another of our posts on the topic or watch this on-demand webinar from our card processing partner Marqeta.

1. Our Open Banking API values observability

Observability is table stakes for Treasury Prime’s banking API. Our RESTful API generates a unique ID for every request, so that if you hit an error or something unusual, you can go back later and track down what went wrong. That means you don’t have to run the request again to find out what happened. As a result, you can avoid having to reproduce the error which (1) may not work, and (2) if it does work, could still waste resources. For example, you could end up accidentally issuing another debit card that you don’t need to issue. 

With our API, if something took 100 milliseconds yesterday, but it's taking one second today, we track it, giving you the observability to find out why. This helps us escalate issues even before our partners notice them, so both Treasury Prime and you can understand if something's changed, if we're doing something different, or if there's a system outage. 

2. Our API is stable

We want to make sure that, as developers are building with our API, you can have the expectation things won’t just change on you without warning. As you build with our API, we’ll tell you about planned upgrades or changes long before they happen. We also build redundancy into our API to prevent stray errors from derailing entire processes. If the API runs into an issue, it tries again. 

3. Our API is third-party tested for security

Security is an important aspect of building an API integration, and there are a lot of different frameworks and approaches out there for achieving it. Our philosophy is that simple is better. 

We offer a simple API authentication model, strong access controls, and activity limits. We also use Cobalt to penetration test our API. We find that third-party penetration testers help us get outside our own heads to make sure we’re checking all the right boxes. 

4. We anticipate outside interruptions before they happen 

We take an asynchronous-first or “async-first” mentality to our software architecture. That means we assume whatever API integration we're building against could go down. Even if the partner we’re working with has never gone down before, it’s still good to anticipate that something could happen. 

Let's say we have an API endpoint that lets you move money between two accounts. The way that our system works is when you schedule that request to move money between the accounts, we split that into two steps. First, we confirm the request and record it. Next, we schedule it to go through. Normally it goes through immediately, but if there’s a problem, we’ve designed the system to try again until it works. That way, if the partner we’re working with has gone down — such as the Federal Reserve’s automated clearing house (ACH) system did early in 2021 — your users are less likely to experience that as your system failing. Instead, they see that their transaction has been initiated, and it clears when that system is back up again. 

5. We’re way ahead on compliance — and you should be, too

A lot of BaaS providers have a one-size-fits-all approach to compliance. And while that might sound nice and easy to a lot of startups, it can also cause major problems. The fintech sector has exploded in recent years, drawing heightened scrutiny from regulators. That means that if your product does something that results in your bank falling out of compliance with regulations, you could damage or lose that bank relationship — and thus hurt your relationship with customers. 

For this reason, we don’t just “handle compliance for you.” Instead, we work closely with top compliance partners such as Alloy and Unit21 to help you build a solution tailored to your company’s unique needs. We integrate deeply with their tools, using all the strengths of our modern API, to ensure you have full visibility into and control over how your product stays on top of compliance. 

Want to learn more about how to evaluate banking APIs? Watch this on-demand webinar from our card processing partner Marqeta. Want to learn more about compliance? We have several blog posts to get you started. 

And Treasury Prime is happy to answer your questions directly. Contact us here. Developers can also learn more about our process by exploring our API reference or playing around with our Developer Sandbox.

← Back to blog