How Moov's OSS libraries fit into a fintech app's stack | Moov

The number one question I get about regarding the Moov open source libraries is, “How do these fit into my application stack?” In this post, we’ll set out to answer this question once and for all. Before we talk specifically about our open source projects, it’s essential to look more broadly at how most companies interact with the banking system programmatically.

The above diagram is a highly simplified version of the most common fintech stack. There are many layers between the payment networks and the average fintech application. However, this simple diagram doesn’t tell the entire story, especially regarding the technical complexity of launching a market solution. In between each layer are multiple data transformations that need to happen.

Let’s dive deeper and view the journey of a single payment through the traditional fintech stack.

Payment data flows by layer

In the below example, we’ll only follow the data in a single direction. Specifically, we will highlight the formats and protocols across the payment details and how they transfer between the layers.

As you can see, a single payment transforms into no less than two different file formats or communication protocols. Keep in mind that this payment data flow doesn’t include the Moov OSS libraries. We’re still talking about how payments flow across current market offerings.

Your application → BaaS API

In the first leg of the journey, you’re sending JSON via a modern REST API. This abstraction of the deeper layers to a modern format is the fundamental value proposition of most banking-as-a-service (BaaS) players.

BaaS API → Bank core system

Here’s where things start to get messy. More often than not, a BaaS provider must convert your data to XML and make a SOAP call. Every core banking system has a different standard. These bank-specific standards explain why most BaaS providers only interface with a single partner, subjecting BaaS provider’s customers to the banking partner’s restrictions.
There is a caveat here. If a BaaS provider or fintech has the technical expertise to generate payment network files themselves, they can skip directly to the next step. Often a bank core system will enable the direct upload of properly formatted files via an FTP server.

Bank core system → Payment networks

Every payment network has its proprietary file format and operating rules. The payment undergoes a final transformation from XML into the ACH flat-file format in our above example. This file then gets broadcast to the ACH network, where the only type of confirmation issued happens when there is an error.

Payment data flows using the Moov OSS libraries

Now that we understand the current payment flows available to fintechs let’s look at how the Moov OSS libraries could fit into your stack. For the sake of this post, we will set aside the issue of setting up and managing the partner bank relationship (often referred to as an originating depository financial institution, or ODFI in fintech speak).

The following diagram and its explanation assume that the example fintech already has an ODFI relationship. We’ll cover setting up an ODFI relationship in a future blog post.

Notice anything different about the above graphic? The BaaS provider is no longer in the mix- . I must stress that even though there can be a technical and competitive advantage to “rolling your own” solution for connecting to your ODFI’s core system, this path comes with a significant regulatory and operational burden. For many companies, going with a BaaS provider is typically the best solution. However, for those who want more control and autonomy, the Moov OSS libraries are here to help. Let’s take a closer look at exactly where Moov APIs come into play.

So what’s going on in this graphic? Why are the Moov libraries contained within the scope of the fintech’s application?

To more easily understand these services, we express them as self-hosted microservices rather than external APIs. This difference can be a significant point of confusion for many people just getting started with Moov.

Now let’s look at how the same payment we showed in the previous examples would flow using the Moov OSS projects.

Your applications ledger → Moov OSS APIs

Your customer initiates a payment that triggers a balance change on your ledger. Your application then sends the data to Moov’s OSS API (hosted on your own infrastructure). The Moov API ingests the data and returns a payment network compliant file ready for uploading.

Your application → Your bank’s core system

When working with a bank directly, they will often give you access to an FTP server you can use to upload files. In this scenario, your application will directly upload the file generated by the Moov APIs in your application.

Your bank’s core system → Payment networks

At regularly scheduled intervals, your bank will send your files to the payment networks for clearing.

When are the Moov OSS libraries the right choice?

As with any technical decision, getting “closer to the metal” is a double-edged sword. If you have a team with experience in banking, compliance, and infosec, then the Moov OSS libraries will save you a significant amount of time. If you’re a small team with less experience in those areas, you may be better off using a more complete hosted solution from Moov or other providers.

Something else to consider is scale. Small teams need to get a product into the market and focus on the one thing that differentiates them. As your company scales, you will need more flexibility and may feel constrained by the “out of the box” solutions provided by your BaaS vendor. If you choose to roll your own solution, we promise you one thing: the OSS libraries from Moov will save you significant time and far fewer headaches.