Meet a mid-size UK lender. They onboarded customers years ago. Core banking holds name, address, risk grade, and KYC refresh date. Product wants a new line of credit. Compliance wants evidence the customer still qualifies. Engineering does not want another S3 bucket labelled passports_final_v7.
This walkthrough follows one application from policy definition to signed outcome. Names are fictional. The constraints are not.
Starting state
- Core record on the lending host (masked account ID, KYC tier, last refresh).
- Sanctions and PEP lists synced nightly to the same VPC.
- Decision service that today emails ops for manual checks.
- Document images in an onboarding archive, not queried for every product change.
Step 1: Define the question narrowly
Compliance writes one sentence: Eligible for Product B if KYC tier at least 2, refresh within 12 months, no active sanctions hit. Everything else is out of scope. No affordability model in this pass. No open banking pull. A narrow question keeps the prove path honest.
Step 2: Map inputs that already exist
| Input | Location | Leaves host? |
|---|---|---|
| KYC tier | Core lending DB | No |
| Last refresh date | Core lending DB | No |
| Sanctions list | VPC object store | No |
| Outcome | Decision service | Signed yes/no only |
If a field is missing, the outcome is cannot prove, not a silent pass. That distinction matters for auditors.
Step 3: Prove on the lending host
AffixIO runs beside the record. It evaluates the policy, returns a signed outcome. The decision service stores hash, timestamp, and ML-DSA signature. Ops sees eligible or not eligible in their existing UI. No new data lake. No nightly ETL of document images.
Sample outcome record (illustrative)
- policy_id: product_b_kyc_v3
- outcome: eligible
- proved_at: 2026-08-28T09:14:00+01:00
- method: on_host_prove
- signature_alg: ML-DSA-65
Step 4: Wire customer-facing gates
For high-risk paths the lender uses Finance Gate to show the same outcome at the channel edge without exposing internal fields. The customer sees approved or referred. The verifier sees only the signed payload.
They did not build a PII warehouse. They built a habit of proving where the truth already lived.
What they did not build
No central PII warehouse. No nightly export of document images. No duplicate GDPR processor for a copy nobody needed. When policy changes, they bump policy_id and re-prove. Historical outcomes remain verifiable because signatures bind to the policy version.
On the host
The prove step
Where AffixIO fits in this KYC example
This walkthrough is a pattern, not a customer story. The lender already had KYC. The missing piece was a new proof on that host, without a second warehouse.
- StaysCore banking
- Runs herepolicy_id prove
- LeavesChannel yes/no
In this pattern, prove deploys on the lending host inside the VPC that holds core banking. The decision service calls prove with policy_id and account reference. KYC tier, refresh date and sanctions hits are read locally. Channel apps see the signed eligible or not eligible through Finance Gate, not the internal fields.
What stays on the host
- The KYC file. No new S3 bucket, ETL job, or second processor agreement in the pattern.
- Policy version. Outcome records bind to the rule that produced them, for later replay.
- SDK wiring. Integration paths are on Developers.
- Ops traffic. Straight-through cases do not need a mailbox of screenshots.
What the channel receives
- Eligible or not eligible. Timestamp, method, algorithm.
- Reuse of onboarding. The bureau work stays once. Prove answers later questions.
- A policy_id change. New rules do not require a warehouse rebuild.
- A trial on your data. Hub proofs run against a policy you define, not a demo persona we invented as a client.
Developers: start at Developers and Product.