What is “real-time” data?
Due to the technical requirements to satisfy a complex global payments platform, Payments Orchestration is a concept that is here to stay. As depicted in the white paper: The Payments Orchestration Layer: Necessary functionality in the payments stack, a payment orchestration layer has four components, smart routers, end-user tools, real-time ledgers, and multiple connections to acquirers and payment methods. Most vendors touting payments orchestration provide some combination of these four components. The rarest of them is real-time ledgers (RTLs).
You may be asking, why are ledgers so important to Payment Orchestration? And, why do they need to live within the payments orchestration layer (POL)? After all, Enterprise Resource Planners (ERPs) already sport general ledgers and separate billing engines also support their own ledgers. Modern enterprise payments require real-time payment processing on a transactional basis. ERP ledgers were never designed to process transactions in real-time, but to aggregate journal entries in a batch process. Billing engines typically track Account Receivables (A/R) but not Accounts Payable (A/P). Because the POL sends and receives transactions, each pay-in and pay-out transaction must be tracked for financial integrity.
For the engineers reading this, RTLs need to perform “near real-time” ledgering. Achieving true real-time reporting is so technically onerous that the drawbacks typically outweigh the benefits. For practical purposes, “near real-time” reporting —- when data is uploaded into a data visualization tool via API —- will suffice. The latency between the API call and the refreshed data uploaded into the merchant’s data visualization tool remains infinitely better than current processes today (e.g. the end of month reconciliation we’ve seen at several enterprise merchants), yet it is not true “real-time.” That’s why, for the purposes of payment orchestration, we identify the recorded accounting that takes place during payment processing as RTLs.
RTLs solve two inherent problems for merchant payments:
- They provide near real-time financial data visibility
- They inherently ensure transactional integrity and idempotency
Global payment operations require merchants to closely manage their liquidity. The traditional approach to manage liquidity has been to develop batch-oriented software and processes which collect detailed transaction information and reconcile payments activity. Customarily, merchants only know the position of key accounts (such as Cash-In-Transit, A/R, A/P, and Projected Revenue & Expenses) after these slow and error-prone processes have been executed. The delays born from these anachronistic processes force merchants to only have a snapshot of their financial environment on a daily, weekly, or even monthly basis. All of this undermines efficient cash management policies.
We’ve also seen merchant systems built without transactional integrity or idempotency inherently designed into the payments stack. The primary reason why this happens is because there are no ledgers built anywhere in the payments platform. In such cases, the only ledger that may exist is the General Ledger in the ERP, far removed from tracking each transaction state. When leveraging Finite State Machines, such sub-ledgering capabilities become essential.
Finite State Machines orchestrate sequential logic flows like:
Figure 1: An example Finite State Machine (Merindol, 2017)
A = Authorization, C = Capture, (p) = pending, (s) = success, and (f) = failure
No more than one single state can exist at a time. This is a core principle to Finite State Machines. It’s useful in that a transaction state will only ever be one thing at a time. That means that data flows have transaction state integrity natively built into their designs. It’s useful for identifying how to triage transactions. In theory, less bugs emerge during testing and deployment too. However, without a ledgering component, errors in the transaction become difficult to diagnose.
In practice, RTLs are a subset of the General Ledger, as the General Ledger is designed for batch entries, not for tracking on a per-transaction basis. They are kept separate from the rest of the merchant technology stack and are the payment platform’s financial book. RTLs immediately and automatically record accounting events as they occur when transactions are being processed. Every sub-account is updated automatically, following predefined rules and actions as determined by a merchant’s accounting department.
Why accounting?
Each transaction state is in an accounting event and ultimately needs to tie back to the accounting events that are reconciled within the ERP General Ledger. By storing a chart of accounts with key liquidity and operational sub-accounts (such as Cash-in-Transit, A/R, or A/P) within the payments orchestration layer, each transaction state can be audited. If machine learning logic is applied to routing conditions, each step can be analyzed to understand the potential reasons behind the routing algorithm’s logic.
For example, a credit card authorization approval from a PSP results in an immediate credit to that PSP’s A/R sub-account and a debit to a merchant prepaid liability sub-account. Another example is when a payout is initiated to a Partner (e.g. a travel agency or a ride-share driver). In that case, the Partner’s A/P sub-account would be credited while the marketplace’s cash sub-account would be debited.
RTLs can be used to track financial activity at the partner level—instead of tracking this activity on an aggregated basis. Besides calculating revenue share, RTLs can also be used to determine—on a per Partner and per transaction basis—not just the cost paid in interchange and card schemes fees, but also all costs allocated to each transaction. This allows merchants and marketplaces to be more granular and transparent with their fees to Partners, while increasing operating margins and/or reducing operational costs.
The increased visibility from RTLs enhances the productivity of the staff charged with managing payments. Treasurers and cash managers are better able to make cash-management decisions when they are informed in real-time. RTLs provide visibility into cash, liquidity, and risk factors, thus enabling holistic financial clarity. Given currency instabilities, the rise of cryptocurrencies as storable assets, and the rise of 24×7 treasury operations, near real-time visibility into the cash coming in and out of a merchant’s coffers is more crucial than in prior years.
***
From the Paladin Payment Vendor Report, Modo Payments leverages RTLs for the benefit of their clients through their COIN platform. Each software module within COIN supports a state change that cannot make any assumptions about what happened before the state change or what will happen afterward. Each state must fully reconcile before the transaction proceeds to the next state. These RTLs allow Modo to always know the actual condition of any transaction within their platform, at any one moment in time, at an atomic level.
To learn more about Modo as well as other services providing payment gateway and orchestration services, download a free edition of the 2020 Payment Vendor Report.