The CustomerIs Not ApprovedBy A Form.
An application is a set of assertions, not a customer. Between the two sit the evidence for each assertion, the checks policy requires, the ambiguity no check resolves, and the person authorised to decide — held as one case until there is an answer somebody can defend.
Next Step / Technical Discovery
- One record across every check
- Linked to the fact it supports
- Versioned at the moment of decision
- A named role owns the outcome
Where this system fits
The onboarding system is where an application stops being a form and becomes a case: facts asserted, evidence attached, checks planned, and a decision a named person is accountable for.
- The rule that settles a case, and the point where it stops applying.
- Each verification service behind one boundary, including when it cannot answer.
- Reviewer roles, queues, and who may approve what inside the business's own hierarchy.
- Policy, risk appetite and regulatory permission belong to the client.
- A decision has to be explainable to somebody who was not there.
- Evidence about a person is held under the rules for holding it.
Why onboarding stops being one decision
- 01
The same fact, asked for four times
Every check keeps its own copy of a name, an address, a date. Nothing states which copy the decision finally rested on.
- 02
The provider answered, and settled nothing
Not a pass and not a fail. There is no state for that, so the case waits where nobody is looking until an applicant chases it.
- 03
A document on screen, and no question attached
The reviewer is shown a scan. Which policy requirement it satisfies, and what would make it insufficient, lives in their training rather than the case.
- 04
Approved, and the reasoning is gone
The account is open and policy has moved twice since. Which version governed the decision, and what the approver saw, is not in the record.
Actors and boundaries
Applicant or organisation
Asserts facts about itself and supplies evidence for them.
Nothing inward. They see what is outstanding and what would resolve it, never the thresholds behind it.
Customer-facing product
Collects what is asked for, when it is asked for.
The platform decides what is required and when. Presentation stays with the product.
Onboarding platform
Holds the case, plans the checks, applies the policy, records the decision.
All of it: case identity, the fact and evidence model, the required-check plan, check-result state, policy version, remediation state, the decision record and its history.
Verification or screening provider
Answers one question about one fact, on its own coverage and timing.
Nothing inward. Their answer is recorded as given, including when it settles nothing.
Operations reviewer
Works referred cases, requests remediation, records what they found.
Outward. The platform assembles the question and its evidence. Reading them is the reviewer's work.
Compliance or approval authority
Sets policy, sets risk appetite, and owns the admission decision.
Outward, entirely. The platform applies a policy it is given and records who approved under it. It does not interpret law.
How much of the decision a rule may make
Three review models. Volume, ambiguity, and the cost of admitting the wrong customer decide between them.
- By policy alone. No queue exists, because nothing should reach one.
- By policy where it is clear, by a reviewer where it is not.
- By policy at low risk; review deepens with what a mistake costs.
- Resolved by defaulting, usually to decline.
- Routed. Every inconclusive result has a queue and an owner.
- Routed by tier, so scarce reviewer time reaches what needs it.
- None by construction. The cost sits in the customers a rule misjudged.
- Grows with applications, whatever their risk.
- Grows with risk rather than volume, which is the point of it.
- Low-consequence admission, and evidence that is either there or not.
- Moderate volume, and a policy whose hard cases are genuinely hard.
- A wide risk spread, where treating everyone alike wastes review or admits risk.
What a check has to come back with
A state, not a verdict
Passed, failed, inconclusive, expired, or the provider could not answer. A case modelling only the first two turns the other three into somebody's memory.
The assertion it tested
A result attaches to the claim it checked, not to the applicant in general. Otherwise a reviewer meets a conclusion and reconstructs the question.
A source and a date
What was consulted and when, so a decision made in March can be read next year without guessing what the provider knew then.
An expiry
Evidence and results both age. A case still open past the point a check stays meaningful has to ask again rather than reuse.
When it fails
Six conditions an onboarding team meets weekly. None is settled by guessing what the applicant meant.
- A verification service cannot be reached
The check has no result, and the case records unavailability rather than a failure.
The case holds where it is and retries on that check's own schedule. Nothing already verified is re-asked.
- The provider answered, and the answer settles nothing
The result carries an inconclusive state rather than a pass or a fail.
The case moves to review with the question attached. A reviewer may accept alternative evidence where policy allows, request remediation, or decline.
- Two sources describe one fact differently
Both attach to the same assertion and disagree about its value.
Neither is discarded. Both are shown with their sources and the case goes to a reviewer, because which is right is a judgement for a person, not a rule.
- A document expires while the case is still open
Evidence carries its own validity date, read against where the case is now rather than when it arrived.
Checks resting on it return to outstanding and that item alone is requested again. Everything independent of it stays verified.
- The applicant changes a fact after checks completed
An assertion that a completed check depended on is amended.
Only the checks that rested on it reopen. Earlier results stay in the history rather than being replaced, so the case shows what was true when.
- A declined applicant applies again with better evidence
The new application matches a decided case on identity.
A new case opens, linked to the old one. The decline is not reopened or overwritten; the new case is decided on its own evidence.
What you own afterwards
- Facts, evidence, check results, policy version and the decision sit in one record, so a question about an admission is answered rather than assembled.
- Inconclusive, conflicting and expired are states with a queue and a person, not conditions discovered when an applicant asks why nothing has happened.
- The policy version that governed it, the evidence the approver saw and the reasoning recorded stay together, so answering a year later is retrieval.
- The platform assembles the case and applies the policy it was given. Who may admit, and on what appetite, remains a role the business names.
Related pages
Payment Platforms
The system that owns a payment's state from initiation to settlement, routes across providers, and produces a ledger that reconciles.
Business Automation
Operational work automated across the systems a business already runs: settled where the rule holds, routed to a person where it does not.
API & Systems Integration
The boundary between systems that change independently, fail differently and sometimes disagree — engineered as a contract rather than a connection.
Bring a review queue nobody has time for, an inconclusive result with nowhere to go, or an approval nobody could explain a year later.