Lab  /  Experiment

Invoice factoring underwriting engine

The part of a fintech I can talk about. The company is in stealth, so there is no name and no link. When it launches, it gets its name back.

StatusIn stealth, waitlist openWhat I didArchitecture and build, soloTypeExperiment

The job

Is this invoice safe to pay today?

Creators wait a long time to get paid by brands. The fix is old: buy the invoice, pay the creator now, collect from the brand later. The hard part is deciding, quickly, whether the deal is real, whether the documents agree with each other, and whether the brand is likely to pay.

That decision is the engine. Everything around it, the brand, the pricing, the partner, stays private until launch.

The bet

Fast for the creator, careful with the money.

The engine makes a recommendation. A person approves the money.

Submitting a deal takes under 300 milliseconds. Underwriting it happens afterwards, in the background, across eight independent checks. The creator watches each step complete live.

The engine is built to earn trust, not assume it. For now it runs in calibration mode: it records the call it would have made, then holds every deal for a person. The reviewer has to write down why they approved or declined, and that reason is saved next to a snapshot of what the engine said at that moment. Every decision becomes a record to calibrate against. When the engine and the people agree often enough, it gets to decide more on its own.

What I built

A full underwriting back end, behind a simple form.

The site saves the deal and its scoring job together, and answers straight away. A dispatcher picks the job up and fans out. Every check that calls the outside world runs as its own microservice, in its own container on a virtualized server, with its own retries. A final step gathers the results once every check has reported. Then a person decides, and the brand confirms before any money moves.

If a data provider is down, only that check waits. The others finish, and nothing is lost.

Creator submitsUnder a secondPostgres queueDeal and job, togetherCheck services, in parallelThe brandDomain, contact, creditThe documentsDocling, then ClaudeThe creatorIdentity, socialGather the resultsSafe to run twiceA person decidesCalibration holdThe brand confirmsBefore money movesUnderneath: Supabase for data, accounts, documents and live updates, Next.js on Vercel for every screen

Scroll sideways to see the whole diagram.

A person approves every deal, for now

Next.js 16 on VercelThe site, the creator flow, the brand confirmation and the console
SupabasePostgres, accounts with row level security, private document storage, live updates
Graphile WorkerA Postgres backed queue, no Redis
Containerized microservicesOn a virtualized server, one per external check
Docling, self-hostedTurns contracts and invoices into structured text
ClaudeReads that text and extracts the deal facts
Identity, company and social data providersFor the checks
ResendAn email at every status change

Eight checks

Three questions.

Is the brand real and able to pay?

Its domain, including how old it is. Whether the contact actually works there. Its credit tier.

Is the creator who they say they are?

Identity verification, and their social presence.

Does the deal hold up?

The contract itself, whether the amount makes sense, proof of delivery, and their history with us.

Inside the engine

Nothing lost, nothing guessed.

A queue that cannot lose a deal.

The deal and its job are saved in the same database transaction, so there is never a deal without a job or a job without a deal. Retries and backoff belong to the queue. A deal that fails every retry falls back to a person with a flag on it. Never silently.

Documents read once, in two stages.

Contracts and invoices are mostly born digital, so there is nothing to OCR. A self-hosted parser turns each file into structured text, tables included, and the files never leave our own infrastructure. Claude then pulls out the parties, amounts, terms and payer. Each document is read once, at upload, on the server, and the score uses that stored reading. The creator cannot hand the engine its own answers.

A cross-check with no model in it.

A plain rule compares the contract and the invoice: amounts, payer, currency. When they disagree, the creator sees the exact numbers and cannot continue. A document it cannot read is held for review, never shown as a pass.

The brand confirms before money moves.

The brand's contact gets a signed, expiring link, reviews the deal and confirms it. Their name, title and IP are recorded.

An operator console.

A review queue, a pipeline board, capital and maturities, collections, brand and creator directories, risk logs, a plain-English risk summary on every deal, and a full audit trail. For the engine itself, a scoring lab to run any single check by hand, and an engine log that traces every deal module by module, with timing and failures, and flags anything stuck.

Talk to me

Building something where software makes the case and a person signs off on the money? I care about where that line sits.

cassandra@instinctai.io

Instinct AI LLC, Tulum, Mexico