opbox

Run a KYC review

Verify a client, record the verdict, and let the system schedule the next review.

Knowing your client is a standing obligation, not a one-time box-tick: you establish who you are dealing with, record the evidence, and keep that knowledge current for the life of the relationship. This guide walks you through one full cycle - find the client, record the KYC verdict, let the system schedule the next review, and re-verify when it falls due.

You do not need to touch the database or write any code. Each step below is a single action, and the system keeps the dates honest for you. For the full picture of how this fits together, see KYC & periodic review.

Before you start

  • A party already exists for the person or organisation you are reviewing. A party is the single record that carries your client’s KYC standing.
  • Recording a verdict and re-verifying are senior-tier actions. Writing identity standing is a privileged, sensitive operation, so it is gated to Admin-tier users and recorded in the audit trail. If you only need to read standing, Member tier is enough. See the sensitivity grading note below.

Step 1 - Find the party

Start by locating the client you are reviewing.

  1. Open the parties register. This is backed by party.list, the firm-wide KYC-expiry register: it shows every party by KYC standing, so you can see at a glance who is verified, who is expiring soon, and who is overdue.
  2. Filter to find the client - by name, by type (person or organisation), or by KYC standing (for example, “show me everyone whose verification has expired”).
  3. Open the client’s full profile with party.profile. This shows their current KYC standing and their relationship graph (directors, shareholders, and so on). If you only need the standing on one record, party.get reads a single party.

The list and profile show you the standing (verified, due, risk level) without exposing the raw identity documents, so day-to-day work never spills the sensitive detail.

Step 2 - Run KYC and record the verdict

Now capture the verification and record where the client stands.

  1. Run the KYC check. Attach a verification check to the party with verification.create. This sends the identity evidence to the verification provider. When the provider responds, the check transitions to its result automatically through verification.update (a provider callback - you do not have to do anything to advance it).
  2. Write the regulated identity facts. The sensitive identity details - the regulated PII - are written with party.facet.set. These facts are encrypted before they are written, sealed at rest, and every read of them is logged.
  3. Record the verdict. Set the outcome on the party:
    • KYC status - for example, verified, pending, or escalated.
    • Risk level - how much scrutiny this client needs.
    • PEP flag - whether the client is a politically exposed person.
    • Sanctions match - whether the client matched a sanctions list.

The standing on the party updates to match the verdict you recorded, and that standing is what drives the rest of the work.

Step 3 - Let the system schedule the next review

You do not keep a manual diary. When you record a verified verdict, the system does the scheduling for you.

  1. On a verified verdict, the system stamps when the verification happened (the verified date).
  2. It then derives the expiry from your firm’s configured validity period. A verified record never lands without an expiry - the two always travel together.
  3. From that moment, the party shows correctly in the firm-wide register (party.list) as current, due soon, or overdue.

Because the standing is derived from real dates rather than a status someone has to remember to update, the register can never quietly drift out of date. An expired party is overdue, by definition, until someone re-verifies it.

Step 4 - Re-verify when due

When the expiry approaches or passes, the client appears in the register as expiring or expired. Run the re-verify path to refresh the standing.

  1. From the register, open the party that is coming due.
  2. Run the re-verify path with party.kyc.review. This:
    • Refreshes the standing fields (new status, risk, PEP and sanctions flags).
    • Sets a new verified date and derives a fresh expiry.
    • Preserves the encrypted identity facts byte-for-byte - the original PII you already hold is never touched, only the standing moves.
  3. The party drops back to current in the register, and the cycle starts again.

Re-verifying gives you a fresh, current verification sitting on top of the evidence you already hold. The cycle repeats for the life of the relationship.

A note on sensitivity and the senior-tier gate

The identity details behind a KYC record are graded as the most sensitive data Opbox holds. They are encrypted before they are written, sealed at rest, and every read is audited - the register shows you the standing, never the raw documents.

Because writing identity standing is a privileged act, recording a verdict (party.facet.set) and re-verifying (party.kyc.review) are Sensitive, Admin-tier operations. They are gated to senior users and recorded so the record can always be defended. Reading the register and a client’s standing stays available to Member-tier users.

For how PII is encrypted and sensitivity-graded across the product, see Security.