willowpays.com
Consumer fintech (bill financing)
Real money rails, and attribution that refuses to flatter.
18,576 SMS delivered in 30 days, at a 91.1% delivery rate
ClientWillow
Read the case →Industries · Fintech
Fintech software development on real money rails.
Fintech software development is mostly money paths: a bill to read, a vendor to pay, a risk to price, a repayment to collect. We engineer those rails, with an audit trail on every step and a switch on anything that moves a dollar.
30 minutes. A written gap map. No pitch unless you ask for one.
✓ Adverse-action codes
every decline explainable, every score in a ledger
every decline explainable, every score in a ledger
Plaid · Stripe · Bill.com
money movement with a row for every dollar
money movement with a row for every dollar
01 · What goes wrong
The demo moves a payment. A lender moves money every business day.
The problems fintech founders and lenders bring us, in their words. One is enough to start asking questions.
- No ledger
Every step touches real money, and nothing writes it down.
A prototype calls a payment API. A lender needs a system of record for every bill read, decision made and dollar moved, or the first dispute, chargeback or customer complaint has no row to point at.
- Black box
Underwriting is a score you pay for and can’t explain.
Paid risk vendors price every applicant, and nobody in the building can say why one was declined. The bill grows with volume, and the model never learns from your own repayments.
- Manual intake
Bills arrive as photos, and someone types them in.
Utility, insurance, phone and auto bills come in every format. Reading them by hand caps volume at headcount, and a single reading model with no fallback fails quietly on the formats it has not seen.
- Unfunded
The ad account counts form fills. The business runs on funded bills.
Bidding learns from signups that never fund, and every platform claims the sale no matter who brought it. Spend decisions get made on the platforms’ version of events.
- Manual
Repayments and collections run on spreadsheets and reminders.
Installments need a scheduler, a call queue and states that know who was contacted and when. Without them the team chases, and nobody can show the consent behind a message.
02 · What we build
The rails a lender runs on, and the growth measured against them.
Both halves in one place, because the ad account can only learn from funded bills if the same team wired the ledger and the conversion upload.
01Intake
Bill reading with guardrails
A layered document pipeline reads bills in any format, with a fallback when the first model struggles and health monitoring on every layer. The model extracts; the server decides; nothing it reads moves money on its own.
02Rails
Payment rails with a system of record
Plaid, Stripe and Bill.com for bank links, cards and vendor payments, wired through webhooks into an append-only event ledger, so every dollar has a row that says where it went and why.
Launch Engineering03Underwriting
A first-party risk model you can explain
Trained on your own repayment outcomes with as-of-submission snapshots, so nothing from the future leaks into training. It serves feature contributions and adverse-action reason codes, sits under hard-fail policy rules, and records every score.
Product Engineering04Servicing
Repayments and collections that run themselves
A repayment scheduler, a call queue and collections states that know who was contacted and when. One-time passcodes gate signup, and operations consoles give the people working the queue one place to look.
05Controls
Controls you can inspect
Audit trails on sensitive actions, read-only data roles, kill-switches on anything that moves money or messages a customer, and penny-exact validation that quarantines a statement that does not add up.
06Growth
Growth measured against funded bills
Offline conversions carry each funded bill’s real value back to the ad platform, a channel view reconciles what the platforms claim against your database, SMS delivery is checked against the carrier’s own records, and email deliverability is monitored.
The Growth Engine
03 · Proof you can check
A fintech in production, and the receipts behind it.
A consumer bill-financing fintech runs on rails we engineer, and we run its growth too, judged on funded bills rather than clicks. The bank-statement reconciliation comes from a finance pipeline we built for an auto group, because the same validation guards a lender’s books. Every figure opens its receipt.
2
paid risk vendors replaced by a first-party, explainable underwriting model
A calibrated LightGBM model trained on the lender’s own repayment outcomes, served with adverse-action reason codes.
receipt
SOURCE · Underwriting-model repository for a consumer-fintech client
METHOD · Model design documents and serving code; both third-party scores are blocked from training and serving by a guard in code.
VERIFIED · 2026-09
CLASS · repository
✓ every number on this site opens its receipt
CLAIM · vendor-replacement
How we count~1,029
funded sales that never reached the ad account, found and re-sent so bidding learned from real revenue
The upload log said it had worked. The ad platform had recorded a fraction of it. Every batch is now confirmed as accepted, with an alert if one is not.
receipt
SOURCE · Offline-conversion upload records reconciled with the funded-sales database of a consumer-fintech client
METHOD · Funded sales from a two-month window compared with the conversions the ad platform actually recorded; the re-sent history was confirmed as landed in the ad account.
VERIFIED · 2026-09
CLASS · platform account
✓ every number on this site opens its receipt
CLAIM · sales-backfill
How we count~33–40%
of funded bills are Google-attributed. We publish it on purpose.
Measured, not assumed. The rest arrive through affiliates, Bing, Meta, email, AI assistants and untagged traffic, and the dashboard shows them too.
receipt
SOURCE · Channel-attribution dashboard for a consumer-fintech client, reconciled against its funded-bill database
METHOD · Ad-platform conversions compared with funded bills in the system of record over rolling windows. Absent data never renders as zero; immature cohorts are labeled, not counted.
VERIFIED · 2026-09
CLASS · platform account
✓ every number on this site opens its receipt
CLAIM · attribution-honesty
How we count10 accounts · 9 entities
bank statements reconciled to the penny, every one checked against its printed totals
Beginning balance plus deposits, minus withdrawals, checks and fees, must equal the ending balance, or the statement is quarantined for review.
receipt
SOURCE · Finance pipeline repository for a 12-rooftop auto group
METHOD · Validation logic and database re-verification in the pipeline; failures are quarantined, never silently included.
VERIFIED · 2026-09
CLASS · repository
✓ every number on this site opens its receipt
CLAIM · penny-reconciliation
How we countThe work behind the numbers
- ClientA consumer fintechA layered document pipeline that reads uploaded bills, with a fallback chain and health monitoring on each layer, so a degraded model shows up on a dashboard before it shows up in a customer’s experience.
- ClientA consumer fintechEvery capability that touches money or messages customers ships disarmed behind an explicit switch: conversion uploads, email writes and SMS alerts stay off until someone turns them on.
- ClientA consumer fintechSeparate test, development and production environments, operations consoles for the team, and a weekly business report that runs on written honesty rules: absent data never renders as zero, and fresh cohorts are labeled until they settle.
- ClientA consumer fintechAffiliate sub-IDs carried end to end through a dedicated mirror landing domain, so partner traffic is credited to the partner that sent it.
04 · How it starts
The ledger first. Then the money paths. Then the model. Then the traffic.
The same order every time, because each step protects the next. You see the plan before we start, and every money path is tested before it is armed.
Already live and spending? Start with the free Growth Engine Audit instead. It ends with a written audit either way.
Step 1: The free Production Gap Review
Bring the product you have, the prototype a builder produced, or the lending model you plan to run. We walk it together, then hand you a written gap map across environments, data, payments, underwriting, collections, messaging and tracking.
Out a written gap map, yours to keep
Step 2: A fixed, scoped plan
If there is a fit, you get a fixed price and a written plan: what we keep, what we rebuild, and why. If there isn’t a fit, we say so.
Out fixed price + written plan
Step 3: Environments and the ledger
Separate test, development and production environments, roles with audit trails, and the system of record go in before any money path is wired, so everything after lands on rows that can be checked.
Out a system of record under test
Step 4: Money paths and intake
Plaid, Stripe and Bill.com through webhooks, the document pipeline with its fallback chain, and one-time passcodes at signup, with tests on every path that moves money and a switch on each one.
Out money paths wired, disarmed by default
Step 5: Underwriting and collections
Hard-fail policy rules first. A model trained on your own outcomes comes when there are enough of them to learn from, served with adverse-action codes. The repayment scheduler, call queue and collections states go in alongside.
Out decisions explainable, repayments scheduled
Step 6: Then fill it
The Growth Engine: offline conversions carrying real funded-bill value, the ad account audited line by line, a channel view reconciled against your database, and lifecycle SMS checked against the carrier, with email deliverability monitored.
Out a next step, not a hand-off
05 · Straight answers
Questions lenders ask before they build.
Can you build the underwriting model, or do we need a vendor?
Both routes work, and the honest order is policy rules first: hard-fail rules catch what a model should never decide. Once your own repayment outcomes exist in enough volume, a first-party model trained on them can replace paid scores, with as-of-submission feature snapshots so nothing from the future leaks in, feature contributions for every decision, and adverse-action reason codes.
We have made that replacement for a consumer fintech. The model is guarded in code so no third-party score can reach training or serving, and every score it produces is recorded in a ledger.
How do you use AI in a product that moves money?
Narrowly. A reading model extracts the fields from a bill, a second and a third take over when it struggles, and each layer has health monitoring. The server decides what happens next, under rules you can read. Anything that moves money or messages a customer ships behind a switch that is off by default, every sensitive action leaves an audit trail, and the data roles the models read through are read-only.
Which payment rails do you work with?
Plaid for bank links, Stripe for cards, Bill.com for paying vendors, and Twilio for passcodes and lifecycle SMS, all through webhooks into one system of record. Other processors fit the same pattern: every movement is a row in the ledger, and the books reconcile against the bank statement, to the penny, or the statement is quarantined for review.
Our ad account reports conversions, but we run on funded accounts. Can you fix that?
Yes, and it is usually the first thing we fix. Offline conversions carry each funded account’s real value back to the ad platform, so bidding learns from revenue instead of form fills, and a channel view reconciles what the platforms claim against your own database. Expect an unflattering number: the share of funded accounts any one platform actually brought in is smaller than its dashboard says, and we publish it anyway.
If the product is already live, start with the free Growth Engine Audit.
Can you take over a platform another team built?
Yes. The gap map is written against the code you have, not a rebuild we would prefer. We keep the product decisions you validated, replace the money paths production demands, and say in writing what we keep, what we rebuild and why. Environments, the ledger and the switches go in first, so the takeover is visible and reversible.
What do you need from us to start?
The product or the prototype, whoever owns the money paths today, and read access to the ad account if it is spending. The review is a walkthrough, so no code has to be sent. Sandbox keys for Plaid, Stripe or Bill.com come later, when the money paths go into staging, and nothing is armed until someone turns it on.
06 · The front door
Find out what’s between your product and real money.
Bring the product, the prototype or the lending model you plan to run. Leave with a written gap map across environments, payments, underwriting, collections, messaging and tracking, before you commit a dollar. If we’re not the right team to close the gaps, the map is still yours.
30 minutes. A written gap map. No pitch unless you ask for one.
- Product live but empty?
Get a free Growth Engine Audit - Not ready to talk?
Get the Production Gap Checklist
info@synaptech.io +1 (925) 255-9507 Pleasanton, CA