Recon Diaries, Entry IV: Building Better Products

Software is changing the role of payments, from an administrative function deep within the belly of a business into a strategic asset that powers products and business decisions. This change has had (and will continue to have) enormous reach and impact—as we say, every payment will begin and end in software.

The commingling of payments and software affects how companies must think about payment reconciliation—tracking, attributing, and accounting for their payments. Reconciliation, in fact, has emerged as a strategic lever to transform payment data from batch-based administrivia into rich, flowing, actionable data inputs. These inputs can be conjoined with other data objects and married with business logic to create efficient products and workflows that drive growth and strengthen client experiences.

In the next few entries of the Recon Diaries, we will illustrate how reconciliation helps move companies forward. To start, we’ll review third-party product payments—money moved on behalf of users and clients. In later entries, we’ll move to first-party financial payments, including traditional receivables and payables.

Why Recon is Tricky: Considering HouseParty

Software, as we know, has eaten the world. It’s now eating payments to unlock new financial experiences and value propositions. Let's walk through an example featuring HouseParty, a fictional property management software platform.

The HouseParty platform stitches together multiple capabilities that help property owners run their operations—these include everything from a vertical-specific ERP and resident services (i.e., tenant underwriting, maintenance portal), to payments (i.e., lease and utility payments), lease management, asset optimization, and marketing.

By coupling payments within property management workflows, HouseParty provides their clients with a clear, connected platform that drives growth and strengthens tenant relationships. It supports a breadth of business needs:

• Secure tenants via lead generation services, tenant underwriting, and lease execution.
• Get paid with resident rent, lease, and utility payments.
• Retain customers with a tenant engagement portal for maintenance requests.
• Pay workers through subcontracting and maintenance payments.

Integrated payments make the HouseParty platform powerful, simple, and easy. Nevertheless, for HouseParty, offering a compelling software payment experience is neither simple nor easy. In fact, under the hood, it demands sophisticated technical gymnastics, especially when it comes to the bank rails. Reconciliation is the foundation for these operations.

In particular, HouseParty needs to execute an end-to-end payment workflow directly within its software platform. This entails enabling a tenant—let’s call him Ryan—to pay rent within the application.

Once Ryan has paid his rent in the tenant portal, HouseParty’s product automatically:

1. Updates Ryan’s rent balance in the tenant portal
2. Updates Ryan’s rent payment within the internal source of truth
3. Pays out rent to Ryan’s property owner, Austin

It’s a series of laddered actions, predicated on a simple question: Has Ryan paid rent?

Answering this question programmatically, however, is far from trivial. In fact, it requires substantial engineering and data expertise. The issue is that the financial information needed to answer this question is difficult to access. The data is locked behind technical and operational barriers, unable to be assimilated within software, and connected with other data objects and business logic. So, while HouseParty’s other workflows move flexibly at the speed of software, their payment data is left behind, siloed and inoperable. We can dig into these complications further.

Understanding Technical Complications

As it stands, banking networks present payment data in outdated, illegible formats. A previous entry of the Recon Diaries underscored how the US payment networks, despite their remarkable ability to coordinate and align, remain technological laggards:

The US payment networks are not modern technological marvels. In fact, they might more closely resemble, as Bill Gates called them, impossible dinosaurs. Most were built in the mid-20th century on COBOL software (the latin of software), run by underpowered mainframe computers. They have limited data capacity; they batch transactions; they take, in some cases, days to clear and settle.

These systems were built and digitized in the 1970s, before the internet, before the cloud. As a result, they deliver payment data in pre-internet (narrow, rigid, spartan) formats.

(One of these formats is the BAI2 file—Ryan’s rent payment might be somewhere inside it)

To even access the transaction file above—which, we hope, includes Ryan’s rent payment—requires a significant amount of technical know-how. Specifically, companies must build:

1. A data integration with their financial institution—built on protocols, such as SFTP and FTP—to receive the data file above.
2. A data parser that translates the coded digits on the BAI2 file into an intelligible list of transactions that’s compatible with modern software.
3. A separate data parser that translates coded payment network files to understand payment failures.

Building this infrastructure takes time and expertise. Moreover, each bank is different. Without a central body, like Visa, MasterCard, or SWIFT enforcing a single data spec, financial institutions are left to interpret and implement their own data reporting. This leads to minor (yet maddening) discrepancies in common file “standards”, such as the BAI2 format. As we’re often reminded: “good fences make good neighbors.”

What’s Behind The Operational Challenges

Furthermore, there are operational hurdles that HouseParty has to overcome to know if Ryan has paid rent.

In a previous entry of the Recon Diaries, we discussed how the bank networks operate via net settlement:

The US banking system is a batch processor, which means that banks process payments in aggregate batches at specified times throughout the day, as opposed to processing individual transactions as they happen. If a company sends ten ACH debit transactions to their bank, the bank might return only three transactions that aggregate those ten debits into three line items. Batch processing grew out of the development of clearing houses. In the 18th and 19th century, check volume grew substantially, which made bilateral (i.e., bank-to-bank) check clearing operationally untenable. As a result, the first check clearing house was established in New York City in 1853. The clearing house facilitated the exchange of checks, and calculated a daily net settlement for each bank. With net settlement, banks fund or draw upon their settlement accounts, which helps to lower the amount of deposits a bank must reserve and reduces interbank counterparty risk.

Due to the operations of the U.S. banking system, the transactions parsed on the BAI2 file are often aggregated. This makes it difficult to confirm if the $6,500 charge (an aggregate of four transactions) indeed includes Ryan’s rent payment.

To confirm this information and utilize, one must:

1. Decipher the batched payment networks into 1-to-1 payment matches

Then, using technical infrastructure developed above, one must make compatible with other objects to:

2. Attribute to a user (i.e. Ryan’s payment), and

3. Associate with a business purpose (i.e. for payout to Austin, Ryan’s property owner)

Reconciliation with Modern Treasury

Without sophisticated software interfaces that address these operational and technical hurdles, bank payment data is inaccessible. It’s locked behind CSVs and batched-based manual reconciliation. It cannot be effectively leveraged within products and workflows to create compelling experiences and drive business efficiencies.

Modern Treasury—as you might guess—provides the infrastructure to solve this. Our operating system offers connected money movement infrastructure—APIs, dashboards, databases and workflows—to unlock data from the banking networks and stream it within financial products and workflows. At the core of this operating system is a reconciliation platform that solves the operational and technical hurdles described above. Modern Treasury’s Reconciliation Platform delivers the following capabilities:

• Bank Integrations. Pre-built bank integrations programmably pull and parse bank transaction files according to their unique configuration.
• Reconciliation Engine. Reconciliation engines employ sophisticated machine-learning matching algorithms to convert batched transactions into confirmed payment line items with 99.9% accuracy.
• Software Tools. Software tools, including Expected Payments, Virtual Accounts, webhooks and metadata, enrich information on bank payment files and connect within a financial graph that includes end-user data and business logic.
• Reconciliation Dashboard. A centralized dashboard allows users to confirm transactions, pull reports, and investigate unmatched exceptions.

HouseParty could rely on Modern Treasury’s OS to build a software offering that plugs into the payment networks and integrates banking data into their software workflows. Let’s walk through how:

• Job 1: Allow Ryan Smith, a tenant, to pay rent within the application.
  • Payments. HouseParty would use Modern Treasury’s Payments API to create a payment order, and automatically transmit that payment to their bank(s).
  • Enrichment. Within the Modern Treasury Payment Order, HouseParty would enrich the transaction with free-flowing meta-data that ties this payment to Ryan’s customer ID (i.e. customer data) and his landlord (i.e. business purpose).

When Ryan has paid rent, HouseParty would automatically:

• Job 2: Update Ryan’s rent balance in the tenant portal.
  • Reconciliation Platform. Modern Treasury would track Ryan’s payment throughout the banking system. Our reconciliation engines and file parsers would automatically confirm when Ryan’s payment has been received on HouseParty’s bank statement.
  • Reconciliation Platform. Modern Treasury would proactively notify HouseParty of Ryan’s payment via a JSON webhook; HouseParty could use this webhook to programmably update their tenant portal to let Ryan know that his rent payment went through.
    
• Job 3: Update Ryan’s rent payment in the ERP system.
  • Reconciliation Platform. With the same JSON webhook, HouseParty would update their own internal ledger to reconcile Ryan’s confirmed payment against their source of truth.
    
• Job 4: Pay out Austin, Ryan’s property owner.
  • Payments.  Using the transaction metadata in the JSON webhook–which attributes the payment to Ryan, and outlines its purpose (i.e., for Austin)—HouseParty could then automatically create a disbursement payment to Austin.
    
• Job 5: Run analytics to power better decisions.
  • Analytics. HouseParty could use Modern Treasury’s push-to-warehouse capabilities to port this payment data to their own data warehouse (Redshift) and run analytics. What is their payment failure rate? When do most tenants pay rent? Who’s consistently late? How do tenants prefer to pay? etc.

Taken together, Modern Treasury offers the connective tissue to build better products, simplifying multiple jobs into one, automated workflow. It also empowers teams to make better decisions by transforming siloed, batched-based data into usable, informative insights.

With Modern Treasury, HouseParty can plug into simple APIs to build software products that harness the power of the bank networks to deliver new value and customer delight.