Continuous underwriting
You underwrote this client once. The client changed on Tuesday.
Underwriting in factoring and asset based lending has always been treated as an event: a file, a decision, a limit, a review date twelve months out. The risk it is meant to control does not work that way. It moves with every schedule, every payment and every debtor who starts paying five days later than they used to.
FactorFox re underwrites on every material event, versions each run immutably, and reports what changed rather than what is. It is built for the credit officer and the underwriter inside a funding company, not for the company seeking the funding.
Underwriting runs · Sunline Packaging
14 versions · none overwritten
- v.14Today 11:05Concentration changeCritical
Exposure under one debtor name across three clients. Position moved to hold on further purchases.
- v.13Yesterday 16:52Payment velocityAttention
Days to pay drifted 9 days against this debtor's own record. Confidence 71%, coverage 62%.
- v.12Yesterday 08:14Schedule submitted
Cleared 8 of 8 gates. Run preserved as it stood at the funding decision.
- v.113 days agoVerification exception
Two invoices held pending confirmation. Evidence captured at run time, never re fetched.
Gate policy · machine may hold · release requires a named human
The gap this closes
Every loss review in this industry finds the same sentence.
The information existed before the money went out. It was in a different report, on a different cycle, in front of a different person.
The loop
What happens between an event and a decision.
This runs whether or not anybody is watching, which is the point. The first a person hears of it is usually the item in their brief.
- Trigger
A material event arrives
From intake, from cash application, from verification, from a covenant test or from the network view of a debtor that several of your clients sell to. Materiality is evaluated first, so a routine payment on a routine invoice does not spend anybody's attention.
- Assemble
The evidence for this run is gathered and stamped
Invoices, aging observations, payment behaviour, documents, verification results, credit results where a source is connected, and prior decisions on the same party. Sources that cannot be reached are named as unavailable rather than skipped quietly, and coverage falls accordingly.
- Evaluate
Signals are computed against the book's own history
Every comparison is against a baseline drawn from your portfolio and this client's or debtor's own record. Where the baseline is thin, confidence is lowered and the run says so. Confidence and coverage are carried as two separate numbers from this point to the surface.
- Version
The run is written immutably and given a version
Nothing overwrites the previous run. You can open the run as it stood at any funding decision, compare two versions, and see precisely which inputs moved between them. This is what makes a later argument about reasonableness a short conversation.
- Gate
Policy decides what the run is allowed to do
The run can hold a schedule, require verification, require a second officer, or clear. It can never release money by itself. Each gate names the specific condition holding the schedule and the authority needed to move it, so the exception queue is actionable rather than a list of red rows.
- Brief
A named person is told, with the action attached
The finding reaches whoever carries that scope, with its severity, its reason, its evidence references and the actions their permissions allow. Anything material outside a person's scope travels the escalation lane and arrives labelled as escalated.
The daily signal set
What is being watched, and what each thing is compared with.
The comparison is the part that matters. A number on its own is a fact. A number against the right baseline is a decision.
| Signal | Compared against | What it can do |
|---|---|---|
| Payment velocity by obligor | That debtor's own payment record with your book | Raises a finding, adjusts the risk position, reorders the collections worklist |
| Dilution movement | The client's own dilution history, tracked as movement not as a ratio | Feeds availability and eligibility, raises a finding when the trend breaks |
| Concentration change | The prior observation, including exposure under one debtor name across several clients | Can hold further purchases against that debtor and trigger a covenant test |
| Invoice size deviation | The client's own median invoice, with confidence lowered on a thin baseline | Sends the invoice to verification rather than blocking the client outright |
| Unusual submission timing | The client's established submission pattern | Contributes to a fraud finding. Never a sole basis for a hold |
| Duplicate and near duplicate documents | Fingerprints within the client and across the whole portfolio | Holds the schedule and names the matching document |
| Bank account changes | The account of record | Human only hold. Automated approval is refused outright and cannot be configured on |
| Availability compression | Net availability trajectory, with days to zero | Warns treasury before a release window rather than during it |
| Covenant movement | The covenants you record, with the clause quoted as evidence | Reports days to breach on the current path and escalates to the owner |
| Missed promises | The promise made, by whom, and the debtor's promise history | Reopens the case with the reason stamped on it |
| Verification exceptions | The verification run captured at run time | Holds funding and names the override authority required |
| Credit limit utilisation | The limit in force, on both the client and the debtor side | Warns before refusal, and shows which side of the relationship is consuming the limit |
Several external credit and legal sources are declared rails that answer not configured until you hold the contract and the keys. Where that is the case, the platform reports itself blind on that source and lowers coverage. It does not treat an empty answer as a clean one.
Asymmetric automation
Stopping money is automatic. Letting it go never is.
Ask a vendor whether their platform automates underwriting and you will usually get a yes that means nothing, because the interesting question is which direction the automation is allowed to run in.
FactorFox recommends broadly and executes narrowly. It will hold a schedule, require a verification, require a second officer, refuse a bank account change, or stop purchases against a debtor whose concentration has moved past policy. Every one of those is a machine stopping money, and every one is reversible by a person with the right authority and a written reason.
What it will not do is release. No configuration, no threshold, no confidence level and no quiet mode lets an automated conclusion put money out of the door. A named human approves, the approval is recorded with the actor, the evidence, the policy version, the confidence and the origin, and the record is immutable.
This is also why the exception queue is worth working. When a hold arrives with the specific gate, the reason, the evidence and the authority needed to clear it, the queue is a list of decisions. When a hold arrives as a red row with a code, the queue becomes something the team clears at four o’clock to get the day finished, which is the exact moment the control stops being a control.
Why the asymmetry holds
A wrong hold costs an hour and a phone call. A wrong release costs the advance, and in the cases that actually hurt, several advances before anybody notices the pattern.
So the two directions are not given equal trust. Four eyes applies by default. In solo mode an AI counter review is logged where the second officer’s name would sit, and it refuses outright when any underlying fact has changed since the request was raised.
The rule lives underneath every surface, so it cannot be avoided by approving from Microsoft Teams or from a phone. A requester who tries to approve their own release is refused by name.
Straight answers
What credit officers ask about continuous underwriting
What counts as a material event?
Anything that could change a decision. A schedule submitted, an invoice verified or failing verification, a payment arriving early or late against the debtor's own pattern, a concentration crossing a threshold, a dilution movement, a credit limit utilisation change, a document that matches a near duplicate, a bank account change request, a promise made or lapsed, a covenant test moving. Events that cannot change a decision do not trigger a run, because a system that re underwrites on everything is a system whose runs nobody reads.
Is this a credit score?
No, and the distinction matters when your committee asks. A score compresses a situation into a number that hides what produced it. An underwriting run states the position, names the signals that moved it, reports confidence and coverage separately, and carries references into the records behind each one. You can disagree with a run and point at the exact input you disagree with. Nobody has ever usefully disagreed with a single composite number.
Can we make a gate advisory instead of blocking?
Some, and deliberately not others. Gate policy is yours to set for ordinary credit and operational conditions. Certain gates can never be turned advisory: the human only hold on a bank account change is the clearest example, and no configuration path exists to automate through it. If a control can be switched off by whoever is under the most pressure that morning, it was never a control.
What does asymmetric automation mean in practice?
The machine may stop money on its own authority. Only a named human may let money through. That asymmetry is the whole design. An automated hold that turns out to be wrong costs you an hour and an apology. An automated release that turns out to be wrong costs you the advance. So the two directions are not given the same amount of trust, and the audit record shows which side of that line each action came from.
How is this different from an annual review with monthly monitoring?
An annual review describes a book that no longer exists, and monthly monitoring finds the problem after four more weeks of purchases against it. Continuous underwriting means the position is recomputed when the facts move, and the run that existed at the moment of a funding decision is preserved. When somebody asks why you kept buying after the pattern changed, the answer is a versioned run rather than a recollection.
What happens when the platform and the officer disagree?
The disagreement is recorded rather than resolved silently. The run keeps its recommendation, the officer's decision is stored against it with their name, the policy version and their written reason, and both sit in the audit packet together. Overriding is a legitimate part of underwriting. Overriding without a trace is what turns one bad file into a pattern nobody can find later.
Related
Bring the file that went wrong.
Every operator has one: the client that looked fine until it did not. We will walk the signals that were already in the data, in the order the platform would have surfaced them, and show what would have been held.