If money is the lifeblood of business, the inflows and outflows of revenue and expenses are like the heartbeat of a company. And while tracking and managing these financial operations are critical to keeping a business healthy, the tools that exist today are incredibly antiquated. Meanwhile, payment complexity is increasing as businesses become more global and seek to add new payment methods every day.
To keep up, many of the largest companies have invested in homegrown solutions and rely on an army of engineers and operations specialists. Companies like Airbnb and Uber have teams of more than 200 simply to keep track of their real-time financial health, both cash on hand as well as payables/receivables.
Worse yet, breakdowns in these payment operations can have massive consequences. Last year, Matt Levine famously wrote about the payments debacle where Citibank wired $900 million to a hedge fund—by mistake. The cause? A set of email approvals and legacy software that didn’t catch the error. And this isn’t an isolated instance—companies spend millions of dollars per year on audits and many more on fines and lost revenue for not tracking payments correctly.
Companies need (and deserve) better software to manage day-to-day finance workflows and make CFOs more strategic. We believe that “financial operations” (FinOps) is an emerging software category with a massive opportunity to rethink the way businesses manage their money by streamlining, automating, and optimizing existing work while giving the entire organization a real-time view of a business’s financial health.
TABLE OF CONTENTS
Pay-ins, payouts—what’s so complex about payments?
TABLE OF CONTENTS
At its core, there are two money movement workflows, the majority of which are manual today.
- Payouts send money outside of the business, including sending money via bank wires and ACH to pay vendor invoices or make disbursements to customers, generating invoices, creating transaction logs, managing pooling vs. custody account flows, and reconciling to the accounting systems/ERP.
- Pay-ins bring money into the business by accepting and adding different payment methods; orchestrating and optimizing payment routes and authorization rates; identifying cases of fraud and failure; allowing for rewards, gift cards, and payment splitting; and reconciling to the accounting systems/ERP.
For pay-ins, payment acceptance methods—credit cards, ewallets, crypto, gift cards, merchant acquirers, bank transfers—differ by an individual company’s needs as well as by geography. Adding new methods can take weeks or months of engineering time to implement. For example, a consumer marketplace may want to accept a new local payment type or e-wallet as they expand into a new market or geography (e.g., Ideal in the Netherlands, or Grab’s consumer wallet in Southeast Asia). This isn’t as simple as flipping a switch in Stripe or Adyen, and it often requires a team of engineers to integrate a payment acquirer, embed it within the checkout flow, and tie it to the ERP.
For payouts, initiating a bank transfer can often mean a complex series of manual approvals sent via emails or CSV files to the bank and then tracked in spreadsheets or software developed 20 years ago (at best). The typical workflow for a fintech lender might include a finance team verifying a loan amount, batching all disbursements into a single daily request list, and then sharing that list with a bank via CSV upload or email/fax. Someone in finance then needs to check with the bank to verify that the payment went through, and manually log that payment disbursal into an internal spreadsheet.
For both pay-ins and payouts, transactions are often reconciled manually, with stale data and no single source of truth. While the ERP is a system of record for the company, it doesn’t have—and isn’t going to build—the capabilities to track real-time financial health. With very limited intelligence around payments, companies are losing out on revenue from failed payments and declines, but they don’t know how to maximize success rates across processors or how they should configure their re-try strategies, when one fails, or to identify insufficient funds for ACH payments for a particular bank account. Nor can they benchmark performance to see how authorization rates compare against the market.
The opportunity to build
The opportunity to build payments software is deceptively large. This isn’t just one company—we expect to see a number of companies build solutions, and potentially even systems of record, for payins and payouts as well as regional approaches across geographies.
Fundamentally, the payin stack and the payout stack focus on different buyers and partners. The payouts stack connects to the company’s banks, and the buyer is typically on the treasury side. On the payins side, the software needs to integrate into and maintain connections into a number of gateways, and the buyer is more likely from the product management side than the finance side.
For both payins and payouts, the current workflows around payments can be organized into layers on top of the existing “primitives,” which are payment methods like bank transfers (e.g., wire, ACH), card payments, e-wallets, as well as payments-adjacent tools (e.g., fraud detection tools, compliance, authentication, tokenization) that influence whether payments proceed.
These layers are:
- Moving payments: Enables programmatic movement of money
- Ledger/reconciliation: The recording of the payment entries and connection to the ERP
- Dashboard: Enables the ability see and search payments traffic (e.g. by country, processor/network/bank, customer type) and
- Intelligence: Offers the ability to set alerts and catch errors, and provide analytics and insights around performance, how to optimize payments, and maximize success rates. This is likely combined with better data (e.g. BIN lists) and benchmarking to understand how authorization rates compare.
Each layer builds on the layer below it, and the data generated and actions taken there. Together, they create the opportunity for new software to replace existing manual work.
The opportunity to build here also differs by geography. Different local payment methods, regional ERP systems, and banking systems and regulations surface different product requirements. In Latin America, fraud rates are high, therefore improving payment authentication (routing to the payment provider with the highest acceptance and accurate fraud risk assessment for a particular transaction) is most attractive. In Europe and Asia, managing a larger number of payment methods is core functionality.
If the technology is involved in the payments flow, the company likely needs a money transmitter license (which are also granted at the local and regional level and can take months to procure). This all translates into different products for Latin America, North America, Europe, Asia Pacific, Africa, etc.
Building principles
Building trust and reducing friction in onboarding are critical to building successfully in this category. The product needs to be reliable given this is critical infrastructure (and trust can only be earned once). Relatedly, the product wedge also can’t create a single point of failure for the customer and likely has to be additive on top of existing products to start, not a replacement of existing infrastructure.
Setup cannot be overly complex as many legacy accounting and treasury management systems require complex setup, integration, training and maintenance, which the buyer wants to avoid. The finance team should be able to connect their payment rails on both the payin (e.g., payment gateways) and payout (e.g. existing bank relationships) and then customize their routing needs to suit their operational workflows or end customers without needing much, if any, engineering resources. No-code/low code or simple tools that enable easy customization work best.
To get to market, early design partners are critical, and lighthouse logos can signal trust to prospective customers. Product marketing is also critical to get right. This is not a set of problems that everyone across an organization is familiar with. Product marketing should be communicated in simple terms and as a revenue and business enabler (e.g., onboard more customers with a new payment method). And that then should be backed by a product that makes it simple for leadership across the company to understand, and get insights into the real-time financial health of the company, and potentially even replace the company’s ERP.
The need for a new generation of FinOps software is only increasing as companies continue to expand globally and new payment methods are created. This infrastructure will be critical to understanding a company’s real-time financial health and empowering the CFO (and their organization) to become more strategic. It’s time to build new payments infrastructure—one that delivers a real-time system of record, can automate manual workflows, and deliver unique insights and organizational intelligence.
