Modern Treasury: Payment Operations Made Easy

Modern Treasury ("MT") is a full-stack payment operations platform

What Are Payments Operations:

Payment operations in layman's terms, essentially means if you're a company that moves a lot of money (say between consumers + drivers like Uber or investors and SaaS businesses like Pipe) you're:

1. Making the right payments to the right people

2. Making sure that all of these inbound/outbound payments are completed, accurate and there are workflows to fix the ones that have errors

3. Making sure that you know how much you actually know how much cash your company has on-hand between all this movement.

As full-stack implies, the company does a lot of cool things but the key features are:

1. On Platform Payment Initiation: Easily allowing a company to send ACH/RTP transactions via API through the customers's bank. Put simpler, creating the fastest and cheapest way to send/receive B2B payments programmatically without having to directly integrate with a bank's infrastructure

2. Bundling Reconciliation and Initiation: Automatically keeping track of and visualizing in-progress transactions, completed transactions/their context, and overall cash flow. Because MT initiates each payment through your bank, they already store the context of each transaction, which makes it easier to reconcile.

3. Controls: Making sure the right users at the company have access to specific financial information and payment initiation functionality

What Modern Treasury Does — The Detailed version:

1. Payment Initiation: Payment initiation is a fancy way of saying originating a payment to a counterparty (e.g through your credit card or bank portal). For most businesses debits (pay-outs) and credits (pay-ins) go through ACH.

   • Programmatic ACH Payments: MT allows you to send ACH payment instructions (credits + debits) in bulk through its API. This saves companies the trouble of having to manually perform the same payment process non-programatically (e.g. through a bank portal).

   • PSP vs. PISP: Programmatic, bulk ACH payments are not new and can be made by either using a PISP or a PSP (MT is a PISP)

     • PISP: involves creating a programmatic connection and relaying the payment instructions to the company's bank, who will then make the ACH payment on behalf of the company to the counterparty. This is what MT does

     It's not a trivial task — creating integrations for relaying payments with individual bank APIs is insanely hard. Each bank has different integration requirements and payment upload requirements (some involve parsing text files!). It's like building Plaid on hard mode

     • PSP: involves the money first being moved from a payer's bank to a third-party (e.g. Dwolla, Bill.com, or Stripe) who will then initiate the ACH from the third party's bank.

     Because the burden of payment is on the third-party instead of the company, each transaction costs more as the 3P has to absorb operational costs (e.g. potential fraud)
     

2. Reconciliation: Reconciliation is making sure that what your internal financial statements (e.g. when did this transaction take place, our current balance) matches up with external financial statements (e.g. the transactions on bank statements).
   
   There are two levels of reconciliation:
   Transaction Level: Can we track every payment and tie it to a statement on our bank statements once completed?
   Balance Level: Once we roll up all pending and completed transactions, does our balance match our current bank account.
   
   That sounds easy right? Well not quite for these reasons (thanks ACH!):

   1. Timing Differences: ACH is asynchronous and there can be up to a 5 day gap between payment authorization and settlement. These "pending" transactions are not reflected in bank balances, which makes calculating real-time cash balance a nightmare:
      
      MT Solution: Automated visibility of in-progress transactions, which are modified and reconcilled in real time once transaction is settled

   2. Batching: ACH will often batch transactions sent at similar times, which will be reflected on external bank statements. So sending out 5 $100 payments might show up as one $500 outbound payment. When trying to reconcile at the transaction level, this becomes a nightmare.
      
      MT Solution: By owning initiation, MT has the context of every individual transaction which it can align to a batch transaction on your daily/monthly bank statement based

   3. Different Accounts: Trying to decipher cash on hand and financial balances when companies are running multiple individual bank accounts/ledgers (sometimes across various banks)
      
      MT Solution: Integrations across multiple banks and ledgers allowing for single balance level view in easy to navigate dashboard

   4. Decoding Bank Statements: When looking at an external bank statement, the descriptions of a transaction are hard to decipher, adding an extra step to reconcile context with the internal transaction description (look at a transaction on your Bank of America App and try reading the code!)

      MT Solution: Software that automatically decodes each individual's bank transaction syntax and ties to context described during payment initiation
      

3. Controls: With the level of financial access on the platform (e.g. full view into financials, payment initiation), a must-have feature is controls on who can access what functionality
   
   These are mostly used by large companies to control access for internal users of the remediation side of the platform (e.g. if a payment failed or hasn't reached a customer yet, giving a support rep access to view transaction details or reinitiate the payment request)
   
   This is more of a "necessary evil" than a differentiator but a deep integration with a support platform like ZenDesk would have massive appeal to "FinTech first" companies like Transferwise, where payment context and support tickets lived in siloed worlds but are both needed for ticket resolution (e.g. track a payment, reinitiate).
   

4. Continuous Accounting: MT has built what they've labeled continuous accounting. By eliminating the need to have an end of quarter close, a company using the software can integrate their current cash balances, as well as categorized inputs/outputs with their financial source of truth (e.g. accounting software) in real-time.
   
   Practically this requires MT building integrations from their source of truth with external accounting/reporting platforms so this balance matches (e.g. Xero, QuickBooks, Workday, SAP, etc.)
   

5. Virtual Accounts: Virtual accounts (“subaccounts”) are temporary accounts that can be used to transact on behalf of a real physical account. The only real difference (besides being temporary) is that virtual accounts don’t hold a balance. MT allows company to programmatically generate these accounts (via their bank) and assign them to whatever customer they need.
   
   There’s a couple of advantages to virtual accounts:

   • They can be used to really streamline visibility and reconciliation which is right up MT’s wheelhouse (e.g single account for a single customer/transaction)

   • They can help for controls on centralized data (e..g if your DoorDash not giving drivers visibility into a centralized account)

   • They’re lower cost/scale better than physical accounts — why open up tons of new accounts as your business scales? Virtual accounts can almost be thought of a financial primitive

Why Now:

B2B payments through ACH and end-of month reconciliation have been core components

• ACH Volume Explosion: It's a little crazy to think, but widespread adoption of ACH for B2B payments instead of cash is a relatively recent phenomenon! Take a look at payments volume over time:
  
  
  
  
  

• Rise of Marketplaces: While MT's product can be used by any company, it lends itself particularly well to marketplaces. Marketplaces sit in between massive amounts of cash-flow turnover and process thousands of transactions a day, which makes reconciliation and closing absolute nightmares.

Competitive Landscape/Growth Opps:

Opps:

• RTP: One of the biggest opportunities that MT has is Real Time Payments.

  RTPs, are as the name describes, instant payments and push-only (replacement rails for ACH effectively). MT is leveraging its bank integrations across the limited number of players who currently support RTP to allow company's to programmatically send payments through these rails.
  
  It's an interesting long term play:

  • MT is betting that instant payments will enable new programmatic payments workflows embedded deep in company's codebases. For example, Uber will create code around delivering immediate payments out to drivers

  • By being a first mover, they are betting switching costs will be high. In this case, if Uber is using MT APIs to build the payment flows RTP enables they are unlikely to switch.

  • But the simplicity and transparency of RTP is largely going to cannibalize the advantages MT has by bundling reconciliation software with initiation.

  • Bank integrations for initiation are hard but replicable and there will be competitor — MT is betting their first-mover advantage scales here faster than their core software loses value.
    

• Cash Management: One of the hottest FinTech startups in the world right now is Ramp. Ramp effectively does the same thing as Modern Treasury, except on a different playing field — reconciling transaction context (by issuing) with spend output for card payments instead of ACH payments. They then use their transaction knowledge to create recommendations to save money.

  MT can also build similar tools to give companies a way optimize cash conversion cycles — what recommendations can they give on payments timings that allows companies to optimize repeat payments in a way that stretches out payables and pulls in receivables?
  

• Cross-Border B2b Payments: MT also has a large opportunity to bring some of their infrastructure to optimizing global payouts. While partner bank integrations currently allow them to initiate and reconcile global payouts with the same efficiency as domestic ones, there is probably a product they will have to build that also lowers costs on these transactions to fully capture the B2b pyaments marketing, perhaps using a 3rd party such as Transferwise.
  

Risks:

1. Open Banking: MT's biggest advantage is the strength of their bank integrations, especially when it comes to RTP. Open banking, which forces major banks to modernize and standardize their APIs for external consumption. This is great for consumers but bad for a company MT.
   
   Luckily for MT, the rate of legislative financial change in the US is errr, not fast and this probably won't happen soon
   

2. Competition:

   • MT's core barrier to entry against new upstarts is similar to Plaid or Zapier's: volume and breadth of integrations (into banks + accounting software).

   • The biggest threat to the company isn't likely to be a new upstart, but rather a large(r) B2C incumbent already integrated into a company's payments flow building B2B payments/payments ops tools if the opportunity is big enough.