How we built Parafin’s capital markets infrastructure

This year, Parafin announced an expanded warehouse credit facility with Silicon Valley Bank, EverBank, and Trinity Capital, a new credit facility with Goldman Sachs and One William Street, and a $300 million forward-flow agreement with a New York-based alternative asset manager. Each deal has a different structure, set of counterparties, and reporting obligations, but all three ran on the same underlying infrastructure.

Capital markets sits in the critical path at Parafin. We fund small businesses through the platforms they already use, and we finance that funding by selling and pledging receivables to our capital partners. Every morning, funding requests and reporting packages are due to lenders and forward flow buyers. If we can't produce them, we can't sell receivables, we can't recycle cash, and we can't originate. There are no days off.

One capital markets platform, many requirements

The obligations of a capital markets program go well beyond a daily funding request. The same underlying data has to answer to a lot of different consumers: receivable-level eligibility and assignment decisions, borrowing base reporting, investor portfolio reporting, payments and cash sweep activity, accounting use cases, reconciliation with our banks and backup servicers, and internal analytics for portfolio and deal monitoring.

Each consumer has different freshness, accuracy, and format requirements. A lender’s borrowing base, an investor’s daily position file, and an internal asset summary can all be different views of the same data plane. That is the core design decision, and it is what makes new deals cheap to add: a new facility is a new view and a new set of rules over building blocks that already exist, not new plumbing.

2021: The monolith

Our first warehouse facility closed in 2021, and we built exactly what a company moving fast should build: one pipeline, purpose-built for one facility's eligibility criteria and reporting formats.

It worked for exactly one facility, but it had several important shortcomings:

It took multiple hours to run, end to end.
It could only run on business days.
It was not safe to rerun or backfill.
Debugging was close to impossible. It was effectively one multi-thousand-row notebook that commingled Python, PySpark, and pandas, and it was computationally expensive because of pandas-heavy, non-optimized code paths.
Worst of all, if it crashed mid-run, there was no way to recover in time to submit that day's funding request. If it crashed, we missed the submission.

The monolith was the right speed-to-market call at the time. But every property on that list becomes disqualifying the moment capital markets sit in the critical path and you have more than one counterparty.

2023: The refactor that became a platform

In 2023, ahead of launching our facility with Silicon Valley Bank, we did the first true refactor. The constraint that shaped it was everything else changing at the same time.

We were commencing the migration from our original cash advance data models to our unified capital product model as we prepared to launch our flex loan product. That forced a multi-product mindset from day one: we couldn't design around our priorities (one product, one facility, one report). The new pipeline had to support products that didn't exist yet, for facilities we hadn't signed yet.

Three decisions from that refactor defined the platform we run today:

Build on the unified product model, not the legacy one. The new pipeline was built on capital product data models so that MCAs, flex loans, and future products would flow through the same tape, eligibility, and assignment logic rather than parallel pipelines per product.
Own the assignment engine. We considered using a vendor to determine which facility each receivable should go to, but decided to build the system ourselves. It assigns receivables based on factors like eligibility, product type, and balance requirements. Because this logic is central to managing multiple facilities, we wanted to keep it in-house so we could test it and adapt it over time.
Componentize everything. We broke the multi-thousand-row notebook into smaller, single-purpose components. Tape building, facility eligibility, assignment, pledge processing, and file generation each became their own component.

The refactor took roughly 2 months of engineering time. It remains the largest engineering investment we’ve made in the platform, and it significantly reduced the engineering work required to add new deals.

How our capital markets pipeline works today

Today, the platform runs as four orchestrated stages in Airflow, every day of the week:

Report build (~36 tasks, about 75 minutes): Builds the receivable and repayment tapes, computes seasoning and per-facility eligibility, runs the assignment engine, and validates the results. That means in excess of 150,000 receivables are re-evaluated nightly.
Balance reporting (about 2 minutes): Fetches bank account balances from our payment operations platform for use in funding requests.
Pledge processing and borrowing base (~17 tasks, about 30 minutes): Executes ownership transfers against our backend system of record, generates lender-ready collateral tapes, computes purchase proceeds and servicing income accruals, and produces the unlevered asset summary.
Investor reporting and monitoring: Ships daily position, purchase, and payment files to our flow buyers, and fires daily summaries into Slack that the team uses for portfolio and deal monitoring.

The platform now runs ~50 single-purpose tasks instead of one notebook. Each task is independently observable, debuggable, and re-runnable. The longest-running task in the entire system takes about 15 minutes, which means the blast radius of any single failure is minutes of compute, not hours. The pipeline runs 7 days a week, instead of business days only, and it's safe to rerun and backfill. We maintain a full development pipeline where changes are tested against production-shaped data before they ship. And when something breaks overnight, we can diagnose the failed task, fix it, rerun from the point of failure, and still submit on time. We have practiced this recovery path, and it is routine.

One data plane, many producers

The platform is cross-functional by construction. It consumes from nearly every system at Parafin:

Backend systems of record: Loan and advance records, ownership transfers, payment orders, and business data, replicated continuously from our production backend.
Payment operations: Bank balances, cash sweep activity, and payment order state from our payment operations platform data.
Data science and underwriting: Repayment forecasts, underwritten IRRs, and risk features captured as of the time of underwriting.
Servicing: Data on whether accounts have been referred to outside collections agencies is sourced from our servicing CRM.

Data moves through a standard medallion architecture. Raw operational replicas are progressively refined through purpose-built reporting layers into the final lender-ready outputs. The output of a pledge run is a point-in-time file that becomes part of the legal and financial record of a sale. Every artifact the pipeline generates is retained indefinitely for auditability.

Because the platform sits downstream of every team, validation has to be structural rather than manual.

How we validate capital markets data

Our validation checks are specific to the data and how it will be used:

Eligibility: Each facility’s eligibility criteria are computed independently, and a receivable must pass all of them before it can be assigned. If a receivable is missing from a facility’s eligibility table, it is treated as ineligible.
Ownership: Before assignment, the pipeline checks every receivable owner against the set of recognized owners. An unrecognized owner raises an exception and stops the run.
Assignment: The assignment engine prevents a receivable from being placed more than once. We check this again in memory before writing the results, then independently against the persisted table after the write.
Table-level checks: We also validate underwritten IRRs, critical balance fields, and whether every expected owner is represented in outbound files. A failed validation stops the files from being sent.

No double pledging, by construction

Given recent frauds in the asset-backed capital markets, lenders today are rightly focused on one question above all: can the same receivable ever be pledged to two parties? We’ve had layered protections against this for years.

Inside the assignment run: receivables owned by any facility are structurally excluded from the candidate pool before assignment begins; the unknown-owner guard fails the run on anything unrecognized; the single-assignment guard makes a second placement impossible within a run; and the dual uniqueness checks block anything that slips through. In our backend, ownership is an append-only transfer log with a database-level uniqueness constraint. Current ownership is derived from the latest entry, so single ownership holds by construction rather than by convention.

Outside our walls, our collateral administrator maintains an independent register of receivable-to-facility assignment and rejects any receivable assigned to more than one facility, while our backup servicer performs an independent weekly double-pledge analysis across our loan tapes.

Adding new capital facilities

The original refactor took about 2 months of engineering time. Adding our second deal to the platform took 2 to 3 weeks, done by one person, on the business side. Today, we stamp out new deals in days not weeks.

Onboarding a facility now means: a new eligibility component encoding the deal’s criteria, configuration for its caps and pledge calendar, and reporting formats mapped to building blocks that already exist. The assignment engine, tape, seasoning logic, validations, and ownership transfer machinery are already there. Since the 2023 refactor, engineering involvement in new deals has generally been limited to review and consultation.

Our capital markets team can evaluate deals based on their economics rather than whether our infrastructure can support them. The same platform can support warehouses, forward flows, and multiple concurrent buyers.

How a small team runs all of this

The platform is operated and extended by a capital markets domain expert working closely with our Merchant Platform Engineering team. Engineering provides guardrails, review, and deep support where it matters, but day-to-day operation and deal onboarding live with the domain owner. That was a deliberate design goal. Engineering is a finite resource, and every hour it doesn't have to spend on capital markets reporting is an hour spent on the merchant platform itself.

Over the last year, we’ve also used AI tooling to help operate and extend the platform. Runbooks are documented and kept current, design principles live in machine-readable context files alongside the code, and we’ve built internal debugging tools that let anyone on the team triage a pipeline issue with full context. This has made it easier for a small team to work on the platform without relying on one person to hold all of its operational context.

Most of what’s described in this post was designed, built, and operated by a very small number of people.

What's next

The platform's next phase looks like more of what it was built for: additional products flowing through the same rails (our card product among them), continued simplification and hardening, and more facilities and structures stacked onto the same foundation, supporting a portfolio that has funded more than 50,000 unique businesses.

If building the infrastructure that moves capital to small businesses sounds interesting, we're hiring: parafin.com/careers.