How Brex Cash Moves Your Money

Brex is re-imagining B2B financial products. We started with a corporate card and then launched our second product, Brex Cash (sometimes referred to simply as “Cash”) — a cash management account run out of our SEC-registered broker-dealer and FINRA member firm, Brex Treasury LLC. It allows companies to deposit cash, send payments, earn interest or dividends, and track spend. One defining characteristic of technology at Brex is that we prefer to build things in house when possible, so that we have control over the underlying infrastructure. Here, we’ll provide a glimpse into Brex Cash’s infrastructure and elaborate on a few of its critical components.

What is a payment rail?

It’s difficult to describe how financial institutions move money in great detail. Not only are there a variety of different mechanisms for doing so, but each one of them is a complex system with its own set of distinct processes. We call these mechanisms payment rails, and currently Brex Cash supports 3 of them: ACH, wire (domestic and international), and check. We won’t describe how each payment rail works at length, but it’s useful for the purposes of this blog post to understand that for every type of payment rail:

• Counterintuitively, no physical dollar bills exchange hands. What we describe as the process of “money movement” is usually just bits flowing through the network.
• The bits comply with a (usually archaic) message format and communication protocol that are used to send and receive messages between financial institutions. The messages contain information identifying the transaction.
• One financial institution initiates these messages, and another receives them. Though the messages may not be delivered directly (instead routed through intermediaries).
• Initiating payments doesn’t always mean withdrawing funds and receiving payments doesn’t always mean depositing funds — financial institutions can, for example, initiate an ACH debit which would pull money from the receiving institution.
• At the end, one account is debited (money out) and another is credited (money in).

Brex Cash Infrastructure

In this section we highlight the important components that move our customers’ money. Even though this is a technical post, we feel that it’s necessary to start at a high level, showcasing how our broker-dealer structure allows us to integrate with a partner bank. We’ll discuss how we send and receive transactions through different payment rails, and what it means for a transaction to be complete. Finally, we’ll end with describing our low-level ledger datastore, which reflects the change in assets for every financial transaction in Brex Cash.

Broker-Dealer Structure

Brex has an SEC registered broker-dealer subsidiary, Brex Treasury, that is a member of FINRA and SIPC. This means we are licensed by FINRA and that we can buy and sell money market funds per our clients’ direction. However, because Brex is not a bank, to achieve the full Brex Cash experience, we work with a partner bank where we hold an account called the Master Custodial Account (MCA). The MCA is an omnibus account, meaning that although each Brex Cash account has its own unique account number, every single deposit arrives into the MCA, and every withdrawal departs from it. The MCA serves as the source of truth for money movement from our perspective.

Moving money on the Payment Rails

Brex Cash allows customers to send and receive payments via ACH, domestic and international wire, and check. For the outgoing transfer case, users enter the information needed to send money, such as to whom, how much, when, and how the money should be sent (which payment rail to use). This information makes its way to our Payment Management service which is responsible for knowing when to send a payment — right away, in the future, or on a recurring schedule. The service also confirms that a payment passes specific fraud and regulatory verifications before being sent. Analogously, it does the same for incoming transfers before displaying them to customers.

We’ve also built isolated services dedicated to each payment rail we currently offer, making it easy to expand to new payment rails in the future. Each of these services is responsible for communicating with our financial partners to facilitate a specific type of transaction. Like the underlying payment mechanisms, the services look similar at a high level. They:

1. Store information necessary to send and receive payments.
2. Encode and decode different message payloads needed for communication.
3. Connect to our financial partners — via a shared SFTP server, REST API call, or other secure communication protocol.

Let’s look at an example of an outgoing wire payment to contextualize this flow. Once the Payment Management system indicates the payment is ready to be sent, we send this information to the wire payment rail service where its information is stored in preparation to be sent to our banking partner. Instead of individually transmitting each wire right away, throughout the business day we periodically check for all pending wire transactions and batch them into a single WITS (World Integrated Trade Solution) file. We then transmit this file to our banking partner via SFTP, and internally publish an OutgoingWireFileUploaded event, which will be consumed by our settlement system, saying we successfully uploaded a new wire file to our banking partner.

Settlement System

When we send or receive a transaction on a given day, that doesn’t mean that the money for it also moves on that day or even the next for that matter. There isn’t a set of rules we can use — the money moves when the MCA says it moves. For this reason, we built the settlement system, responsible for tying transactions that we know about in Brex Cash to transactions in the MCA. At a high level, the system announces to the rest of Brex Cash when money moves for a given transaction, i.e. when it settles. The importance of this cannot be overstated, as it allows us to get money to and from our customers on time and also has massive operational implications. Overall, the settlement system can be thought of as maintaining eventual consistency between Brex Cash and the external world.

The system relies on a reconciliation framework that we created internally, which allows us to reconcile Brex transactions and MCA transactions on an ongoing basis throughout the day. Whenever we communicate with our financial partners to send or receive money, we publish an event through Kafka, an open-source distributed event streaming platform, with the details of the transactions. The settlement system consumes these events, and creates appropriate line items to be reconciled. For example, when we upload a file containing Wires to our partner bank, we publish OutgoingWireFileUploaded which in turn expands into Reconciliation.Items.OutgoingWire line items using Elixir Protocols. Similarly, we periodically query our MCA transaction feed, and create the opposing line items for any new transactions that we see.

Eventually, when a line item is matched (either automatically via our in-house matching engine or manually by our Operations team), we know that the transaction has settled and several things occur:

1. We update various internal states to reflect the transaction settling.
2. The transaction goes onto the customer’s monthly statement.
3. We reflect the moved money in our Core Ledger (described next).
4. The funds get swept into (or from) Money Market Funds or an FDIC insured account offered by one of our program banks.

This is primarily done through the use of callbacks, which the reconciliation framework also exposes through Elixir Protocols. These callbacks allow us to perform arbitrary actions when a line item is matched, and also when a line item is unmatched for a long period of time.

Core Ledger

The Core Ledger serves as the central tracking system for Brex Cash customer assets. This is perhaps the most important and highest throughput system we have, so we’ve dedicated a lot of effort to make it secure, performant, and uncomplicated. Every single asset movement that occurs within Brex Cash gets written to the Core Ledger, including transactions settling. As one of the final steps in the transaction flow, we record the fact that money has moved, ultimately moving assets into the customer’s possession in the case of deposits and out of the customer’s possession in the case of withdrawals.

Naturally, this is the system also responsible for answering various questions about customer balances, for example:

• What is the total value in USD of all assets held with Brex Cash?
• What is the available balance for a given customer?
• How much did a given customer have in money market funds at a specific time in the past?

Similar to how the MCA is the source of truth from our perspective, the Core Ledger is the source of truth from the perspective of our customers.

Conceptually, the idea behind the design is simple and battle-tested (for centuries): a double-entry ledger. We use the concept of subaccounts, which are essentially named accounts that hold assets/liabilities — these can be thought of as some balances that we want to track over time. Each Brex Cash customer has multiple subaccounts (13 at the time of writing) — this decomposition means we can always get answers to the questions we care about, such as those listed above.

Writing to the Core Ledger involves posting a journal entry, an atomic grouping of changes to subaccount balances. Journal entries are always the consequence of financial transactions, and all the balance changes in a single journal entry must sum to 0, since we never want to artificially create or destroy assets. For example, when we sweep a customer’s MCA balance into Money Market Funds at the end of the day, we post the following journal entry:

In order to read the balance of a specific subaccount, we simply sum all the changes to it over time. Notice that at its core, the system is based on the event sourcing paradigm — we have an immutable, append-only log that we aggregate over for reads. This provides a really important property for us: we are able to easily track down how a given subaccount arrived at its balance.

To illustrate an example of how the Core Ledger is used in practice, sending out a single wire has several touchpoints with it. First, we read to determine that there are sufficient funds in the Cash account. If successful, we then post a journal entry to move the funds from the customer’s available balance to the customer’s held balance in our MCA — this ensures customers cannot spend more than available. When the transaction settles and the money has been withdrawn from our MCA, we move the funds out of the held balance and into another “sink” subaccount to denote that they have left Brex. Finally, at some point we might also sell some of the customer’s MMFs to net out the resulting balance delta in the MCA — that process too would involve multiple interactions with the Core Ledger.

The road ahead

This post has outlined at a high level how we move money — from how our broker-dealer structure allows us to work with a partner bank to move funds via the payment rails, to the settlement system we’ve built that ultimately reflects the net asset change in our Core Ledger. There are, however, still lots of other systems and processes we didn’t get a chance to dive into here, such as our entire Treasury infrastructure. As Brex Cash continues to onboard more customers we will continue to expand our product offering and make companies’ financial processes simpler and easier. Interested in building financial software and services for every growing business? Come join us at Brex!

Special thanks to James Russo for co-authoring this blog post, as well as contributors including David Schechter and Brian Maloy.

The Brex Mastercard® Corporate Credit Card is issued by Emigrant Bank, Member FDIC. Terms and conditions apply. See the Brex Platform Agreement for details.

Brex Treasury LLC is an affiliated, SEC-registered broker-dealer and member of FINRA and SIPC that provides Brex Cash, a program that allows customers to elect to sweep uninvested cash balances into certain money market mutual funds or FDIC-insured bank accounts at program banks. Maximum FDIC insurance of $250,000 per program bank. Investing in securities products involves risk, including possible loss of principal. Brex Treasury is not a bank and your Brex Cash account is not a bank account. Wire transfers, both inbound and outbound, are free to send for Brex Cash customers. For customers sending wires, the recipient’s financial institution may charge a fee upon receipt of the wire. Please see brex.com/cash for important legal disclosures. Past performance is not necessarily indicative of future results.

You could lose money by investing in a money market mutual fund. Although the fund seeks to preserve the value of your investment at $1 per share, it cannot guarantee it will do so. An investment in the fund is not insured or guaranteed by the Federal Deposit Insurance Corporation (FDIC) or any other government agency. The fund’s sponsor has no legal obligation to provide financial support to the fund and you should not expect that the sponsor will provide financial support to the fund at any time. Although the fund’s board has no current intention to impose a fee upon the sale of shares or temporarily suspend redemptions if the fund’s liquidity falls below certain levels, the board reserves the ability to do so after providing at least 60 days’ prior written notice to shareholders. These money market mutual funds are suitable for investors who are seeking as high a level of current income as is consistent with preserving capital and maintaining liquidity.

Uninvested Balances in your Brex Cash Account will initially be aggregated with Uninvested Balances from other Brex Treasury customers and deposited in a single account at LendingClub Bank (the “Clearing Bank”), an FDIC-insured federal savings bank. Within two business days funds are transferred to a disbursement account at a Brex Treasury Third-Party Service Provider (the “Settlement Account”), and then swept automatically into omnibus deposit accounts established by Brex Treasury in its name on behalf of Brex Treasury customers at designated “Program Banks”.

Only the first $250,000 in aggregate deposits at the Clearing Bank will be subject to FDIC coverage. FDIC coverage does not apply to deposits while at the Clearing Bank or any account at an intermediary depositary institution. Deposits that are in the Settlement Account while in the process of being swept to or from a Program Bank will be subject to FDIC coverage of up to $250,000 per Customer.