Knowing your client is not a one-time box-tick. It is a standing regulated obligation: you have to establish who you are dealing with, capture the evidence, and keep that knowledge current as long as the relationship lasts. Opbox turns that obligation into a tracked, repeatable process. Every party carries its own KYC standing, the sensitive facts behind it are encrypted, and a verified date plus an expiry date keep the whole register honest about what is current and what is overdue.
What it does
KYC standing lives on the party, not in a side spreadsheet. Each person or organisation you act for carries a single, current record of where they stand, and that record drives the work.
- A clear standing on every party. Each party has a KYC status (for example, verified, pending, or escalated), a risk level, a PEP flag (politically exposed person), and a sanctions match flag. You can see at a glance who has been cleared, who is elevated risk, and who needs a closer look.
- The sensitive facts are encrypted. The underlying identity details - the regulated PII - are stored as encrypted facets, graded as the most sensitive data in the product. They are encrypted before they are written, sealed at rest, and reading them is itself audited. The party list shows you the standing (verified, due, the risk level) without exposing the raw documents, so day-to-day work never spills the sensitive detail. See Security.
- A verified date and an expiry that drives re-review. When a party is verified, the system records when it was verified and derives when that verification expires from your configured validity period. A verified record never lands without an expiry. That expiry is what makes periodic review automatic: the register can tell you who is current, who is due soon, and who is overdue, all derived from real dates rather than a status someone forgot to update.
- A firm-wide expiry register. Across every party you hold, you can read the whole book by KYC standing - who is expired, who is expiring, the earliest date coming due. This is the overdue / upcoming view that lets a compliance lead see the firm’s exposure in one place.
- A dedicated re-verify path that preserves the facts. When a review comes due, re-verifying a party refreshes the standing - new verdict, new verified date, new expiry - without touching the encrypted identity facts. The PII is preserved byte-for-byte; only the standing fields move. You get a fresh, current verification on top of the evidence you already hold, and the original encrypted record stays intact and audited.
How you use it
The process is the same shape every time, whether a person drives it from a screen or an agent runs it on your behalf.
- Run KYC on a party. Attach a verification check to the party. This captures the identity evidence and records the encrypted facts against that party.
- Set the verdict. Record the outcome - the KYC status, the risk level, and whether the PEP or sanctions flags apply. The standing on the party updates to match.
- The system schedules the next review. On a verified verdict, Opbox stamps the verified date and derives the expiry from your validity period. From that moment the party shows correctly in the firm-wide register as current, due soon, or overdue, with no manual diary entry to keep in sync.
- Re-verify when due. When the expiry approaches or passes, run the re-verify path. The standing is refreshed and a fresh expiry is set, the encrypted facts are preserved untouched, and the party drops back to current. The cycle repeats for the life of the relationship.
Because the standing is derived from dates, the register can never quietly drift out of date: an expired party is overdue, by definition, until someone re-verifies it.
The kernel verbs behind it
Every action goes through the one front door - permission-checked and audited before it runs. These are the verbs that power KYC and periodic review.
verification.create- attach a KYC / verification check to a party (provider-backed). This is “run KYC”.verification.update- the provider callback that transitions the check to its result, idempotently.party.facet.set- write the typed KYC facet: the regulated PII, encrypted before write and read-audited.party.kyc.review- the re-verify path: refresh the standing fields, set a fresh verified date, derive the new expiry, and preserve every encrypted PII facet byte-for-byte.party.list- the firm-wide KYC-expiry register: every party by derived standing (expired, expiring, earliest due).party.profile- the full party read, including KYC standing and relationship graph; the sensitive facets are read-audited.party.get- a single-party read for the standing on one record.
Setting a verdict and re-verifying are Sensitive, Admin-only operations: writing identity standing is a privileged act, gated and recorded so the record can always be defended.
Why it holds up
The point of all this is that you can prove it. The verified date and expiry are real, derived facts, not a label someone typed. The identity evidence is encrypted at rest and graded as the most sensitive data Opbox holds, and every read of it is logged. The re-verify path is built so a refresh can never silently destroy the evidence it sits on. Put together, that gives you a KYC programme that stays current on a schedule and produces an audit trail that stands up to scrutiny - which is exactly what the regulation asks for.
See Security for how PII is encrypted and sensitivity-graded across the product.