Credit and risk
A credit check is evidence about a moment. Treat it as anything else and it stops being evidence.
Written for the credit officer and the underwriter at a factoring company or asset based lender, at the point where a party is created and somebody has to decide what to believe about them.
Network payment behaviour, commercial credit, tax lien position and additional client assessment, each running the moment a party is born, each attaching to the file as dated evidence, and none of them ever refreshed underneath a decision that already used them.
Debtor created · Halloran Freight Systems · birth checks
Coverage 4 of 5Probity network
captured 08:14
Paid to terms on 3 clients. Slowing since March
AML and sanctions
captured 08:14
No match. Rescreened daily
TaxRock
captured 08:14
No federal or state lien found
Ficoso
captured 08:14
Assessment attached to the client file
Creditsafe
unconfigured
Not configured. No contract or keys held by this tenant
The greyed row is not hidden. The underwriting run reports coverage of four sources out of five, and states its confidence separately from that coverage.
The doctrine
Captured at run time. Pinned to the decision. Never re fetched.
Most credit tooling refreshes. A file is opened, the integration calls the vendor, the current answer is displayed, and the screen shows the party as they are now. It feels helpful. It quietly destroys the only thing that made the original approval reviewable, because the evidence beneath a decision has been replaced by evidence that arrived afterwards.
FactorFox captures the answer when the check runs and keeps it. The result is stored as dated evidence, attached to the party and to the underwriting run that consumed it. Reopen that run in a year and it still shows the score, the rating, the lien position and the network behaviour exactly as they stood when an officer read them and put their name to a decision.
New information becomes a new observation, not a correction. Risk observations are append only at the database level. A later check does not overwrite an earlier one, it sits beside it with its own date, and the difference between them is itself something the platform can show you.
Continuous underwriting re runs, and versions each run immutably. Re underwriting on a material event is the right behaviour. Silently swapping the inputs of a completed run is not. Each run reports its confidence and its coverage separately, so a confident answer built on half the sources reads as exactly that rather than as agreement.
Certification signs over the snapshot as it stood. When somebody certifies, they are certifying a specific set of gate results, and an audit packet built from them is sealed with a database trigger refusing mutation. Nothing about the record can be improved after the fact, including by us.
The one line version
A decision is defensible only if you can still see what it was made from.
Every other property of a credit integration is negotiable. This one is not, which is why it is enforced in the platform rather than left as a habit for a careful officer to maintain.
The sources
Five rows, three statuses, no rounding up
Two of these need a contract you may not hold. They still appear in the interface, named, greyed, and honest about what your file is missing.
| Source | Status | What it answers | What protects it |
|---|---|---|---|
| Probity network | Available | How this debtor has actually paid across the FactorFox network, answered instantly at the moment the debtor is created. | No vendor, no contract, no per check charge. Nothing leaves your tenant, and tenant isolation is enforced at the database level. |
| Creditsafe | Contract required | Commercial credit on debtors: company identity, score and payment rating, attached to the debtor file as evidence. | The rail is built and answers not configured until you hold a contract and keys. Results are captured at run time and never silently refreshed. |
| Dun and Bradstreet | Contract required | United States client credit at intake: business identity and credit, attached to the client file. | Same posture as every other bureau rail. No keys, no silent behaviour. Offered only where the tenant country qualifies. |
| TaxRock | Available | Federal and state tax lien position on a prospective or existing client, attached to the client file and to the underwriting run that used it. | One computation serves the intake drawer and the underwriting engine, so the two can never disagree. Pinned to the decision, never re fetched underneath it. |
| Ficoso | Available | Additional client side risk assessment at intake, for the file where one source is not enough. | Same run time capture and the same evidence binding as every other check on this page. |
Creditsafe and Dun and Bradstreet require your own contract because bureau data is licensed to the institution that consumes it. We are not a reseller and we do not want to be one, because a relationship you hold directly is one nobody can interrupt on your behalf.
Why this exists
The check was run. Nobody can prove what it said.
Every credit file that has ever gone wrong has the same forensic shape: the decision is documented, the evidence behind it is not, and the reconstruction happens under pressure.
Probity network
The question a bureau answers slowly, answered from behaviour you are already part of
It is not a cheaper bureau. It is a different question, asked of a different body of evidence.
Behaviour, not opinion
How a debtor has actually paid, drawn from the network plane rather than from a model's view of their filings. The two are different objects and an underwriter should have both.
No per check economics
No vendor, no contract, no charge per lookup. The commercial shape of a check changes how often it gets run, and a check that costs nothing gets run on every debtor rather than on the ones somebody worried about.
One plane, one answer
It reads the same plane the debtor credit file reads, so the number on the intake screen and the number on the credit file cannot disagree with each other.
Nothing leaves
Your book stays in your tenant. The network already knows what it knows about a debtor, which is why the answer requires no export of your data to produce.
Instant at creation
The check runs when the debtor is created rather than as a task somebody remembers later, which is the difference between a control and a habit.
Evidence, like everything else
The result is captured, dated and attached. It is not a live figure that redraws itself the next time somebody opens the screen.
Straight answers
What a credit officer asks about these sources
What does a check being pinned to a decision actually prevent?
It prevents the most quietly corrosive failure in credit software: opening an approved file six months later and seeing today's data next to yesterday's decision. When that happens the decision looks wrong or looks lucky, and either way nobody can defend it. A pinned check means the file shows what the officer saw at the moment they approved, so the review is about the judgement rather than about the passage of time.
Why show a check we have not bought instead of hiding it?
Because a greyed row teaches and a hidden feature lies. An underwriter who sees Creditsafe greyed with the vendor named learns something true about their own file: a source exists, it is switched off, and the assessment in front of them was made without it. An underwriter who sees nothing concludes their coverage is complete. The second one is how a thin file gets treated as a full one.
Does Probity network cost anything per check?
No vendor, no contract, no per check charge. It is not a bureau relationship at all. It reads payment behaviour the FactorFox network already holds about a debtor, which is why it can answer immediately and why the answer is about how that debtor actually pays rather than about how a scoring model rates them.
Does anything about our book leave the tenant when we run a network check?
Nothing leaves your tenant. Tenant isolation is enforced at the database level rather than in application code, which is the distinction worth probing in any multi tenant platform, because isolation written in application code is one forgotten filter away from a disclosure.
Do adverse credit events reach us automatically once a party is on the book?
Not from the bureau rails, and the platform says so rather than implying otherwise. Several external sources are declared and dark, and where a monitoring answer depends on one of them the platform reports itself blind and names the missing source. What does move continuously is behaviour the platform observes itself: payment velocity by obligor, dilution movement, concentration change, credit limit utilisation and missed promises.
We hold a Dun and Bradstreet contract already. What changes on day one?
You enter your keys and the check starts answering at the moment a client is created, with the result attaching to the client file and to the underwriting run that used it. Nothing about the rail changes, because the rail was already built and already visible in the interface as a source you had not configured. That is the whole intent of publishing contract required as a status rather than as a footnote.
Related
Ask to see a check that is switched off.
Any vendor can demonstrate a successful lookup. Ask instead to see a source you have not bought, greyed and named, and watch what the underwriting run says about its own coverage.