Automating and building business processes for scale right from the start is a key

component to creating better experiences for customers and businesses alike. This eBook
digs into how to think about setting up your payment operations stack and key
considerations for a growing company.

CHAPTER 1

Payment Ops Architecture Overview

Money movement on a large scale requires multiple elements to keep the “payment
operations machine” running. Frictionless, organized, and efficient payment operations are
critical to a well-functioning company. From start to end, the lifecycle of a payment involves
five main functions that span several teams across the company:

● Payment initiation: Initiating a transaction via a chosen payment rail (see chapter 2
for more information on payment rails). This can happen via API, through a bank
portal, or by hand (a swipe of a card or the writing of a check). Depending on your
set up, there can be various roles that initiate or approve initiation of payments.

● Compliance: Ensuring that each transaction is following state and federal

regulations, such as KYC/KYB and AML compliance laws, as well as the rules of the
governing body through which the payment is flowing (e.g., Nacha’s web debit rules
for authorizing an ACH payment).

● Ledgering: Logging and tracking each transaction to an immutable, double-entry

ledger database. This gives your company a normalized way to monitor every
payment moving in and out of your accounts within a single source of truth.

● Reconciliation: Matching each payment within your system to your bank

statement, and making sure that each transaction is the right amount, sent or
received from the right counterparties, during the right time period.

● Cash visibility and treasury: Understanding which funds are flowing through
which accounts, what you're earning on those accounts to maximize your bottom
line, and how much you have on-hand to exercise at any given moment.

Setting Up Your Payment Operations Architecture 1

While each function serves a different purpose, the systems that manage them are often
intertwined and affect many teams. As you consider setting up your payment operations
architecture, it’s important to consider whether you want to run some or all of these
functions via a single operating system or multiple systems, how many bank accounts will
be touched, and who the key stakeholders are.

CHAPTER 2

Important Questions to Ask

As you think about how you want to set up your payment operations architecture, here are
a few questions to help you get started:

➊ Have you established a corporate bank partnership?

This requires finding a bank partner that will work for your company’s needs. Some
banks are more willing to work with startups than others; some banks have been
set up to specialize in specific industry verticals. Other banks may have rigid
eligibility standards, fee structures, or longer integration timelines that don’t align
with fast-growth startups. Finding the right bank partner that can not only work
with your company now, but as it scales, is an important decision.

As you think about which bank—or banks—to work with, think about what
accounts you might want to set up and what the structure of those accounts
should be. Are you going to need virtual accounts, or would you want to set up an
FBO, or “For Benefit Of,” account for your products to help manage your user
funds without assuming ownership?

➋ Which payment rails will you use?

The most effective payment rail can vary depending on use case, and it is not
uncommon for businesses to use multiple payment rails, especially bank rails. The
bulk of B2B payments take place over bank rails because they tend to have larger
transaction sizes and volumes. In 2021, the global B2B payments market size was
$125T, and is projected to reach $314T by 2031, a nearly 10% compounded annual

Setting Up Your Payment Operations Architecture 2

 growth rate (CAGR)1. In contrast, the global P2P payments market was $1.9T in
20202.

Different Payment Rails Offer Advantages

Setting up payments looks different for every startup, particularly those that
occupy different industries. If a startup sells goods, services, or subscriptions to
consumers or small businesses, they most likely rely on credit card payments. New
innovations have recently made it easier to accept credit cards on and offline, with
platforms like Stripe, Square, and Adyen.

When considering payment rails, factor in elements like speed, cost, ubiquity, and
transaction limits into your decision. For instance, wire transfers are instant and
typically get used for higher-dollar volume payments, but cost more than other
options. If speed is a factor, instant rails like RTP and FedNow can be good
options, as they are cheaper than wires; however, they are constrained by which
banks offer them and by transaction limits (right now, these are $1M for RTP and
$100K for FedNow).

ACH works well for sending lower dollar volume while giving you the ability to pull
funds directly from customers—most businesses transact via ACH for this reason.
It’s also cost-effective, though you sacrifice some speed—for regular ACH,
payments arrive within 2-3 days. Your decision in selecting payment rails will
depend on the functionality you need and your bank’s capabilities.

➌ What are the regulatory and compliance requirements

for your business?
Every industry and payment rail adheres to specific regulations around money
movement. It’s important that startups are aware of these rules. While your startup
might follow regulations, it’s possible that you could be held responsible should
one of your customers be out of compliance. Aside from assessing customer risk
with KYB/KYC procedures, and complying with Anti-Money Laundering (AML)
laws, there are also money-transmission laws to consider.

1
B2B Payments Market: Global Opportunity Analysis and Industry Forecast 2021-2031. Allied Market Research, Sept.
2022.
2
P2P Payments Market Outlook. Allied Market Research, Sept. 2021.

Setting Up Your Payment Operations Architecture 3

 Money transmission is generally defined as the act of receiving currency or other
value that substitutes for currency (money orders, stored value cards, etc.) from
one party for the purpose of sending it to another party. Money transmitters are
required to register with the FinCEN and acquire licenses in every US state (except
Montana) where residents can use the business’ money transmission service.

Historically, money transmitters were businesses like remittance providers.

Western Union and Moneygram are classic examples, with money transmission
regulations in the US being originally written with those types of businesses in
mind. These regulations have not caught up to today’s reality where money
movement is increasingly a feature in products and services. The broad scope of
regulations can also potentially impact new types of businesses like online
marketplaces, bill payment software, and P2P payment apps.

Any business looking to move money through its products or services needs to
consider how money transmission laws might apply to their business model. This
can be challenging, especially for companies serving the entire US market, since
money transmission laws vary significantly between Federal and State
jurisdictions, and between different states—and they are notoriously tricky to
apply existing guidelines to new business models and technologies.

➍ Which stakeholders will manage your payment ops?

Some companies have finance teams managing payment operations. These
teams are often made up of controllers, payments consultants, payroll analysts, or
operations specialists. They spend their days ensuring the efficient flow of
payments. The accuracy of maintaining records and payment transparency grows
more important when multiple thousands or millions of dollars are at stake.

Yet more and more, product and payments teams are becoming more involved in
payment operations. This is due to new business models, such as embedding
financial services, that require the technical teams to become involved in payment
operations. Across teams and systems, there needs to be controls and processes
to manage payment operations seamlessly.

Setting Up Your Payment Operations Architecture 4

CHAPTER 3

Considerations for Setting Up Payments

Deciding Whether to Sit in the Flow of Funds
The first consideration for your business is whether your product will sit within the flow of
funds or not. The “Flow of Funds” is the movement of money in and out of bank accounts.
Flows can vary depending upon the number of times money moves, currency, payment rail,
type of business, goods or services provided, who runs the business, and asset types.

When money moves, it always moves from one bank account to another. The flow of funds
is composed of one or more “hops” of money between bank accounts, which may be
owned by you, a third-party processor (TPP), customer, or vendor. The flow of funds is a
common way to understand a business and model payments risks.

How does the Flow of Funds work?

There are generally four models used to track the “hops” the money takes from the source
to its ultimate destination, be that one or more hops. In its simplest form, this looks like:

A Diagram of Flow of Funds Models.

Setting Up Your Payment Operations Architecture 5

Different types of businesses can use each method; we’ll illustrate each method with the
example of an online marketplace, Modern Desks, a place where businesses can sell and
purchase used office furniture. Buyers pay and that money makes its way back to the
Sellers. In each method, the Buyer is the Source and the Seller is the Destination.

Method 1: Direct
In a direct approach, money flows directly from the Source to the Destination. In this case,
Modern Desks is not in the Flow of Funds. Modern Desks is simply displaying the Seller’s
goods but not processing any payments directly. Perhaps when a buyer clicks on a used
desk to purchase, they are taken off Modern Desks’ website and onto the Seller’s website
where they can pay.

Given this Flow of Funds, there is virtually zero risk or liability to Modern Desks; they never
touch the money, and therefore they are not liable should the Buyer issue a return.

Method 2: Third Party Processor

In some cases, money moves through a third party processor (TPP), who will temporarily
hold the funds in a separate account while a transaction is being processed. This adds
another “hop” in the flow.

For Modern Desks, perhaps they have a “Purchase Now” button, which collects the
Buyer’s banking information and initiates a debit. The debit will be the TPP (not Modern
Desks) pulling the money from the Buyer’s bank account. The TPP will then later transfer
that money to the Seller (less Modern Desks’ fees).

The key benefit of this method is reduced liability. These liability benefits are typically seen
if the TPP has a strict compliance program, requiring them to limit amounts transferred,
verify identities, and ensure that the originating account can cover the cost of the
transaction. However, because the third party processor takes on this liability, there are
often fees associated with using one. Additionally, the fact that they hold funds, means the
payment will take longer to settle.

Method 3: Business in the Flow

This has the same amount of “hops” as Method 2, but instead of a third party processor in
the middle of the source and destination, it’s Modern Desks.

Setting Up Your Payment Operations Architecture 6

Now, Modern Desks has a “Purchase Now” button on their website, but they will be the
one directly debiting the Buyer’s bank account to their own account. When the funds settle
in Modern Desks’ bank account, they will credit those funds (less fees) to the Seller.

Being directly in the flow of funds, Modern Desks is liable for any risk in the two
transactions: pulling money from the buyer, and pushing money to the seller. The riskier of
these is pulling, or debiting, from the buyer. However, if most of Modern Desks’ buyers are
larger corporations who have funds to pay for their goods, they might assess this flow of
funds as “low risk.”

There are also benefits in this method. The first major benefit is cost. Most TPPs charge a
high percentage fee for just the transaction alone. The second major benefit is a completely
custom flow of funds, only restricted by your bank. Sitting in the flow of funds gives
businesses the most control over user experience, timing, and more. The final major benefit
is control of risk tolerance and compliance programs.

Method 4: Third Party Processor + Business

This model is similar to Method 2. The same issues apply, but in this case it can be more
financially risky given the TPP first sends money to Modern Desks which is later transferred
to the Seller.

Should the Buyer issue a return against the TPP, the TPP will immediately issue a return
against Modern Desks’ bank account. The return costs Modern Desks money, and Modern
Desks will have to cover the balance if they already transferred the money out to the Seller.
In some cases, TPPs may only offer Method 2 or Method 4 based on their agreements with
their banking partner. For example, they may be forbidden to hold funds on behalf of a
customer’s customer or be restricted to only paying out verified direct customers.

Sitting in the Flow?

If your business decides to sit in the flow of funds, you’ll need to figure out if you are going
to build your own bank integrations to incorporate payment capabilities into your product.
This decision also comes with its own risks and benefits.

Setting Up Your Payment Operations Architecture 7

Deciding to Build or Outsource Your Bank Integrations
Building your own bank integration involves building transmission, reconciliation, and
accounting capabilities.You will also need to integrate payment capabilities into your
product, automating core payment flows if applicable.

Typically, large companies that process high volumes of payments benefit from building an
integration. They have a full team dedicated to the process. For a startup or growing
company, building an integration is possible, but difficult since most of these types of
companies either lack the payment expertise or tech resource capacity.

Different banks also have different requirements, which can also vary based on payment
rail. Alternatively, companies can seek out a payment ops solution with expertise in building
to multiple banks and rails. It all depends on whether one wants to spend the capacity and
time on establishing these functionalities, or focusing on core products and strategy.

CHAPTER 4

Establishing Your Ledger Database

What is a Ledger Database?
A ledger is a log of business events that have a monetary impact, captured in double-entry
format. By abstracting balance mutations, purchases, payouts, interest calculations, wallet
withdrawals, fees, and the myriad of other payment ops stuff you need to track as a simple
entry on a double-entry database, you can simplify your work. No more balances and
payouts tables on Postgres; an application ledger database abstracts all of this into two
classes of objects: accounts and transactions.

Setting Up Your Payment Operations Architecture 8

A (well-designed) ledger should:

● Act as a central data store divorced from your underlying fund flow structure (i.e.,
bank account setup, your application data models, or the data and the money you
hold on a third-party system like Stripe);

● Depict transactions in a double-entry format, as it is the millennia-old standard for

tracking financial data

● Handle scale (as opposed to your ERP and accounting system, which is also
double-entry, but best used for historical reporting, not real-time data handling).

Why Outsource Your Ledger

Let’s assume the following is true:

● Your business is buying from an infrastructure company (with entire teams of

engineers dedicated to keeping ledger infrastructure running),

● Such support from engineers is baked into the cost, and,

● This infrastructure company and said engineers have a track record of success.

Under these assumptions, building a ledger in-house almost always ends up being more
risky, expensive, and complex than buying.

The Hidden Cost of Building a Ledger

At its core, building a ledger is a challenge in three forms: it’s an accounting challenge, a
computer science challenge, and a data coordination challenge:

The accounting challenge

Building double-entry logic in a database correctly is a non-trivial technical task. As we
wrote in accounting for developers, building a double-entry ledger entails creating a
translation layer between business events and accounting entries. The alternative is to not
use double-entry at all, which leads to all sorts of issues, as made public in the examples of
Uber, Square, and Airbnb.

Setting Up Your Payment Operations Architecture 9

Assuming double-entry is desired, you’re better off having the support of a trusted partner
in thinking through the transaction handling logic. Most ledger providers will work with you
on this (we do). Having a partner to learn best practices from accelerates the time to go
live, assures scalability, and prevents downstream issues in accuracy.

The computer science challenge

As we covered in how and why homegrown ledgers break, single-entry ledger databases
break down when they are too opinionated or when systems of checks and balances start
to fail. At a more fundamental level, however, scaling a double-entry database is hard.

Does your system accept eventually consistent balance aggregations? Or does your use
case require some level of immediacy on balance updates? How do you deal with the
inherent limitations of the database you use? What kind of concurrency controls do you
need to ensure the ledger is consistent at scale? How do you handle versioning, locking,
and partitioning? These are not trivial issues, and a good vendor tends to have answered all
of these questions with dedicated infrastructure teams.

The data coordination opportunity

Finally, a good ledger acts as a central source of truth. A flexible ledger is crucial in a world
where (1) fintech stacks are bloated, (2) transaction data is sprawled in payment systems,
card issuing APIs, embedded lending providers, and (3) ERPs are good for reporting but
simply not performant enough to inform your product. Instead of figuring out how to parse
logic by yourself, a partner can help—ideally with both direct integrations and guidance.

Setting Up Your Payment Operations Architecture 10

Buying A Ledger Database is Cheaper Over Time
To illustrate our point, we plotted a list of features we believe are important in a ledgering
system. From the top, we have the foundational features: the ledger itself, immutability,
idempotency, etc. The lower on the list, the more requirements are use-case dependent.

The inflating costs of building a ledger

*Note: The cost assumes $250k / year all-in engineering salaries, assuming $197,204
average total compensation for an engineer in San Francisco and baking in fringe costs
such as benefits and taxes paid by the employer.

Many developers see the task of setting up tables of SQL as trivial. But enforcing
double-entry at the database level requires you to organize the database around three core
objects: accounts, transactions, and entries. Accounts need constraints that
enforce account normality. Transactions need to accommodate two or more entries, and
each entry should include a direction property, defining whether it’s a credit or debit.

On top of this, you need to create rules that will assure credits = debits on a transaction
level. You also need to ensure the ledger features an append-only design (for the sake of
immutability), and you need to create idempotency controls to ensure duplicate

Setting Up Your Payment Operations Architecture 11

transactions are properly handled. The list goes on: these are database challenges that
take a team of two engineers four to five months—or about $200k—to get right.

From here, you need to build for scale. Parsing transactions simultaneously, ensuring high
throughput, low latency, and high availability, and implementing locking—these are all
guardrails for any scaling company. Building and testing this could take a team of two
engineers another four to five months. Because of the nature of this problem, the mythical
man-month principle applies here: more engineers don’t necessarily make this faster.

Finally, as you grow, you will inevitably deal with scaling challenges. As we showcased in
how and why ledgers break, more often than not, initial implementation designs fail
overtime, consistency is compromised by scale, refactors become necessary, and as a
result, your cost x time graph ends up looking lopsided, instead of a line.

Lopsided cost curve Ideal cost curve (a line)

Risk: the value of keeping your data with a trusted third party
The risk of using an external provider usually takes one of four forms:
● Performance risk (your vendor not performing according to SLAs);
● Data security risk (your vendor losing access to, leaking or being vulnerable to
attacks on very important data);
● Vendor risk (the chance of your provider running out of business);
● Lock-in risk (the inability for you to move vendors if necessary).

Setting Up Your Payment Operations Architecture 12

On the flip side, the risks of building in-house are:
● Human error/performance risk (your team not building well the first time due to lack
of expertise or competing priorities);
● Timeline/scope creep (building the right thing but in a way that takes way too long
and that costs more money);
● Technical debt (building the wrong thing or building the right thing the wrong way).

We believe that a trustworthy third party can minimize vendor risks while eliminating the
risks of building in-house. At Modern Treasury, for instance, we have ambitious SLIs around
availability, latency, and throughput. We implemented SSO, SOC I and II compliance, RBAC,
data encryption in transit (TLS 1.2) and at rest (AES-256-GCM), IDS, ingress and egress
filtering, and more, to minimize the likelihood of security breaches. Working with some of
the largest fintechs and marketplaces in the world (ClassPass and TripActions, for example)
means our APIs are battle tested. Finally, we don’t believe in locking you in unnecessarily,
so your data can always be exported to your data warehouse of choice.

Some vendors provide similar features; others don’t—what’s important is that you do your
diligence in the process. But working with a trustworthy vendor means you are putting the
three risks of building in-house (human error, scope creep, lack of guidance) under the
scrutiny of a partner who has done this hundreds of times.

| The end result: faster infra → faster products → better companies, out of the box

For many companies, all of this translates into faster product velocity: launching a new
product faster because you will neither have to build—nor maintain—a double-entry ledger
service. Faster time to market means quicker revenue and lower burn. But beyond the initial
launch, outsourcing this undifferentiated part of your stack means peace of mind. Having
engineers focused on your ledger at all times takes time away from your product. And just
like your cloud provider, as your vendor works to continuously improve their infrastructure,
your infrastructure gets better, too.

Setting Up Your Payment Operations Architecture 13

CHAPTER 5

Get Started
There are a number of challenges facing companies that move money. Being able to
automate and build processes for scale right from the start is a key component to creating
a seamless, easy-to-manage experience for customers and businesses alike.

Modern Treasury’s end-to-end platform empowers companies to build products that

exceed customer expectations, unlock revenue, and drive efficiency. We can automate
your business’ payment operations—from user onboarding to payment initiation to tracking
and beyond—to equip you with faster payments, full data visibility, more efficient financial
workflows, and seamless bank integrations. If you’re interested in hearing more about how
Modern Treasury can help you set up your payment operations stack, get in touch with us.

Setting Up Your Payment Operations Architecture 14