The KYB file never closes

A KYB file looks like a form: entity documents, beneficial owners, expected activity, a risk rating. It gets verified once, at onboarding, with a checklist and a deadline, and the project is declared done.

Then the entity keeps living. Ownership changes hands. A dormant account wakes up. Expected activity stops matching observed activity. The file that was accurate in March is a liability by November.

US supervision treats this as the bank’s problem, correctly. Since the CDD Rule’s applicability date in May 2018, beneficial-ownership information is kept current on a risk basis, with triggering events forcing a fresh look. In practice that means periodic refresh plus event-driven review, and that is the actual workload. Onboarding is a project with an end date. The refresh is a standing queue, and the queue is where review capacity goes to die.

A queue needs an order it can defend

A refresh queue of ten thousand files needs an order, and a bare score does not survive contact with a reviewer. The first question on the floor is always the same: why is this one first? A score that cannot answer gets ignored, and the queue quietly reverts to oldest-first.

So the scores carry their reasons. A reviewer sees why row one is row one, before deciding what to do about it, and the act of reading the queue is itself a logged event.

Where this runs matters as much as what it computes. In a KEZEL deployment the case workflows and the queue run beside the core account and transaction stores. The query plan itself carries the masks: a card number is masked for the analyst role in the plan, before a result exists to show, and a cleartext read by the fraud team is one more row on the ledger.

The examiner gets the same ledger. Question, rule, reader, timestamp, one row per read, with lineage from any figure in the exam pack back to its source tables. Compliance walks in with the trail instead of reconstructing it the week before.

The decision in the middle

None of this makes a judgment call. The machinery decides what a reviewer sees first, and it writes down what happened. Those are the two things a refresh program can industrialize; the decision in the middle still belongs to someone with an opinion about the customer.

The pattern comes out of DBTEZ’s consulting work in the US banking domain, where KYC and KYB orchestration is a recurring engagement. The banking page walks the full case lifecycle, refresh loop included.