Skip to main content

Reviewing KYB cases

Every KYB submission is a case. This page walks through how a reviewer works one in the Zyphe Dashboard: finding it, reading what was checked, clearing what blocks it, and deciding it. The rules a decision follows (who may decide, when a second signature is needed, how screening matches are treated) come from your compliance policy.

Cases can be worked by users with the ORG_ADMIN, ORG_OPERATOR, or AML_OFFICER role. Other roles that can see KYB results get the full list of results under Show all results. See Manage Users for the full permission matrix.

KYB results​

Open KYB Results in the sidebar. The page lists every KYB case your organization opened, one row per case: a company can have more than one, for example its onboarding and a later periodic review. You can also reach a case from the Inbox, which gathers what is waiting on you across KYB and your other work, with what is overdue under your SLA targets.

Each row shows the Company, the case Type (Onboarding or Periodic review), its Status, Risk, Flags, when it was Opened, its Last update, who it is Assigned to, and the Decision with who took it. Flags call out what needs attention on an open case: Sanctions hit, PEP, Adverse media, Register mismatch, Missing documents, and Owner KYC pending. A case an analyst opened themselves is marked Analyst; the sandbox's sample case is marked Sample.

KYB results page listing one row per case with status, risk, flags, and decision
Every case, one row each, with filters behind the Filter button.

To narrow the list:

  • Search company or case ID.
  • Filter by Status, Case type, Risk, Flag, Flow, Assignee (including Assigned to me and Unassigned), Opened (a period), and Opened by (Applicant, Analyst, or Migrated). The filters stay in the page address, so a filtered list can be bookmarked or shared.
  • Display → Group by → Company nests each company's cases under one row.

From a row's ⋯ menu you can:

  • Open case.
  • Assign… or Change assignee…: assign the company to a reviewer. An assignment belongs to the company, so it applies to every case of that company.
  • Override risk…: set the rating by hand, with a reason and an expiry. Raising it is always allowed; lowering it is allowed only if your policy permits downward overrides and you have the authority for the level being left. End risk override… ends one early, and Risk override history lists every override.

The buttons at the top open New case (see Open a KYB case yourself), Metrics, Quality reviews, and Show all results (the table of every KYB flow result, with search and filters).

The case page​

Open a case to see everything about it on one page. The header stays visible as you scroll.

Case page header with Approve and Reject buttons, status, screening, stage, due diligence, and risk
The case header: status, screening, stage, due diligence, risk, and the decision buttons.

The header shows:

  • Status: the case status.
  • Screening: whether the company's and its people's screening is complete.
  • Stage and Assigned to.
  • Due diligence: Simplified, Standard (the default), or Enhanced. Enhanced adds a financial-documents requirement; otherwise the checks are the same at every level. Changing it makes the case plan its checks again.
  • Risk: Low, Medium, High, or Critical, the worst of the company's risk score, its screening, and each person's screening and KYC. A confirmed match keeps the rating high even after approval. How it is computed shows the breakdown.
  • Report: download the KYB report Zyphe generates from the case as it stands, or upload and download the report the decision seals. The same generated report is available from your backend through the Node SDK.
  • Approve and Reject when the case can be decided (see Deciding a case).

Above the header, Latest agent review summarises the KYB agent's last run on the case and when it ran, for example "Zyphe Agent suggests approving the case". While the agent is working, the page says so. The sandbox's sample case carries a Sample badge: it is a fictional company, is not billed, and cannot be deleted.

Documents and declared information​

Business Information Clarifications compares each field the applicant declared with what the documents and the official register say, graded Exact Match, Partial Match, Mismatch, or Not Found. Select a field to see the agent's reasoning and every source.

To resolve a discrepancy, use Ask for a clarification: the applicant is asked to confirm or correct the selected fields, and you review each answer (old value next to new value) before accepting it. Send Email requests a named document instead.

Business Information Clarification screen where the applicant confirms or updates the requested fields
What the applicant sees: they confirm or update the requested fields and explain the change.

The Document Checklist lists every document the company's country requires. Each upload is classified and checked automatically:

  • Document check: whether the file is the document it claims to be (for example, Correct document or Wrong document).
  • Checks: each field read from it (issuer, issue date, shareholders, directors, and so on) marked Match, Mismatch, Not found, or Not checkable.

A reviewer can override any check; the override is recorded next to the automatic verdict.

Document checklist with document check and per-field checks for each uploaded document
Every upload is classified and its content checked against the case.

Register documents lists the official documents the company's register holds. Listing them is free; buying one spends credits. This is not available in the sandbox.

To ask for a document your flow marks as on demand, request it from the document list (or from your backend with the Node SDK).

Case activity​

Case activity is the workbench: what the case is waiting for and everything that happened to it.

Case activity card with the Waiting for list and a clarification proposal
What the case needs before it can move on, and who owes it.
  • Waiting for: every outstanding item, with who owes it and since when: a blocker, an open screening match, an exception needed before approval, a proposal to answer, a second signature awaited, a quality review due. Show jumps to where you act on it.
  • Clarification proposals: when the cross-check finds fields that do not match, it proposes asking the company about them. Accept opens the clarification request; Decline drops it.
  • Steps and runs: each check of the case and its latest run. A failed check can be confirmed by a reviewer with a reason and evidence (for the register, ownership, director, and cross-checks; not for screening or KYC), or run again.
  • Verification coverage: each requirement of each subject, and how it was covered (for example, verified by the register or by an interactive check, screened by name, or Nothing provided when the flow did not collect that part). Coverage shows what was actually checked, which a rating cannot: an unscreened company can still rate Low.
  • Exceptions and Decisions: the history of each, with who acted and why.
  • Agent reviews: every review the KYB agent ran on the case, newest first. See Agent reviews.
Verification coverage table listing each requirement, its subject, and how it was covered
Verification coverage, read against the policy version in force.

Proposed changes​

When the flow's case planner is AI proposals or Organization's rules, Proposed changes lists the changes suggested for this case, such as requiring a step, raising the due-diligence level, widening screening, or asking the owners or directors to complete KYC. The planner can only propose changes that make the case stricter. A reviewer accepts or refuses each one; a refused change is not proposed again. In Auto-pilot, changes apply on their own, except ones that need a choice (such as which KYC flow to use).

Agent reviews​

Each review shows its outcome (Recommended approval, Asked the company for more, or Escalated to a person), how many findings and open questions it left, and when it started. Details opens the full run:

  • the Verdict and the Residual risk, and whether the platform guard overruled a recommended approval;
  • the Findings, each with its mitigation, and What it could not close;
  • What it looked at: each source the agent consulted when it researched on its own (Register record, Ownership graph, Adverse media, Web search), with its outcome: Adopted, Purchased, Searched, Skipped, Refused: over the limit, or Failed;
  • the Research spend, Searches, Tokens, Model, and Prompt versions the run used;
  • Show what the panel was sent: the exact input the review read, checked against the hash the run recorded. If the input changed after the run, the page says so.

Company screening​

The screening card lists every match found for the company and its people, by category (sanctions, PEP, adverse media, other), with the match score and the details the list holds. A Relative or close associate of a PEP is a PEP match: the card shows who they are Tied to, and your PEP policy governs it like any other PEP match.

Sanctions match cleared as a false positive, with the reviewer's reasoning and the discriminators
A sanctions match cleared as a false positive, following the agent's proposal.

Each match gets a verdict:

  • False positive: the match is not the subject. It needs at least one discriminator: date of birth, nationality, tax or ID number, address, gender, or another reason with a note. Only a false positive releases the match.
  • True positive: the match is the subject.
  • Undetermined or Customer contacted: the match holds while you find out more.

Each match also shows where it stands: Needs a verdict, Cleared, Holding the case, Cleared by approval (a confirmed match the case was approved with), Ignored by policy, or Rejected by policy.

The AML agent can propose a verdict with its discriminators; you can follow it or record your own. A verdict is not edited afterwards, and it carries over to the same match when the company is screened again.

Where your policy rejects a category (for example PEP or adverse media), a true positive in it blocks approval outright: no exception can clear it. Sanctions matches are always reviewed, whatever the policy says.

People​

People lists the owners and directors of the company with their roles, KYC status, and screening.

People table listing the owners and directors with their roles, KYC status, and screening
Owners and directors, with their KYC and screening status.
  • Add person adds an owner or director to the case; removing someone's role cannot be undone.
  • Request UBO declaration and Request director declaration ask the applicant to declare that part again (available when ownership discovery is enabled).
  • From a person's menu, Send reminder re-sends the KYC invitation, and Open KYC result opens their KYC.

A person without an email is screened by name only (Name-only (AML screen)) and cannot be invited to KYC.

Ownership structure​

When ownership discovery ran, Ownership structure draws who owns the company, with unresolved branches marked. You can extend individual branches, or add the structure by hand when discovery is off. State or public ownership records whether the owners include a state or public body.

Audit trail​

Audit trail is the case's full history, newest first: submissions, checks, requests, verdicts, exceptions, decisions, planner and agent runs, with the actor, the action, and the details. It is the same record a decision seals, so what you read here is what an examiner is handed.

  • Filter by record type and by subject (the company, or one of its people).
  • Each line says what kind of record it is. Lines marked Audit log are on the tamper-evident audit log and can be checked against its chain. The others are the case engine's own records, vouched for by the case's sealed reports.
  • An agent run is anchored on the audit log when it ends; a run that changed afterwards is flagged Changed since it ended. For planner and agent runs, Show what the planner was sent and Show what the panel was sent check the recorded input against its hash.
  • Download explanation dossier exports what the AI did on the case and what people decided, for answering a data subject's request. With a subject selected, it downloads that person's dossier. Zyphe never sends it to the person: decide with your counsel what to disclose.
Audit trail card with record-type and subject filters, Audit log markers, and Download explanation dossier
The case's audit trail, filtered on one subject.

Deciding a case​

Approve is available when the case is Ready for review; Reject also from Action required. Every decision is final: it is never rewritten, and remediation happens by reopening the case.

Approve the case dialog with a reason field
Approving: a reason is optional on a clean approval.
Reject the case dialog with a reason code selector and a required reason
Rejecting: a reason is required, and a reason code classifies it.
  • A reason is required on every rejection, and on an approval that rests on an exception or on a confirmed match. It is optional on a clean approval.
  • A reason code classifies the decision so regulators, metrics, and quality reviews can count it: CDD_INCOMPLETE, SANCTIONS_CONFIRMED, PEP_CONFIRMED, ADVERSE_MEDIA, OUTSIDE_RISK_APPETITE, SUSPECTED_FRAUD, APPLICANT_UNRESPONSIVE, or OTHER. Without one, a decision that owes a reason is recorded as OTHER.
  • Your approval matrix decides who may approve at each rating, and whether a second signature is needed. See Approval matrix.

The decision sends one webhook (verification.kyb.completed or verification.kyb.failed), and a sealed decision package records the coverage, exceptions, signatures, and policy version behind it.

Exceptions​

Some things block an approval until a reviewer takes responsibility for them, for example provider results still pending, open clarifications, or a fallback your policy does not accept (such as screening a person by name only). Record an exception covers exactly one of them, with a reason and an expiry date. Recording one needs the authority to approve that rating "with an exception" in your approval matrix, and it can be withdrawn.

An exception never clears a true positive in a category your policy rejects. Separately, a step can be waived (proposed, then approved), but sanctions and PEP screening and the platform's mandatory steps can never be waived.

Two signatures​

When your approval matrix asks for a second signature, the first Approve or Reject records a proposed decision instead of closing the case. The case header then shows who proposed it, with Confirm and Withdraw proposal.

Case header showing a decision proposed by one reviewer and awaiting a second signature, with Confirm and Withdraw proposal
A proposed decision waiting for a second signature.
  • The confirmation must come from a different person holding one of the awaited roles. The proposer cannot confirm their own proposal.
  • An API key or the KYB agent can take the first signature, never the second.
  • A proposal lapses if the case, its screening matches, or the policy in force change before it is confirmed.

After the decision​

Quality reviews​

Your policy can draw a share of decisions for a second look. Quality reviews lists the decisions waiting for one, oldest first. Nobody reviews a decision they signed.

Quality reviews page with a decision waiting for a review
Decisions drawn for a second look.

A reviewer agrees or disagrees, with a reason. A disagreement reopens the case, even an approved one, and sends a verification.kyb.review webhook.

Periodic re-review​

Your policy sets how long an approval stays valid. When it expires, the case is reopened for a new review, and a verification.kyb.review webhook is sent.

Metrics​

Metrics shows how your KYB decisions were taken over a period, by flow: how many approvals were fully covered, how many decisions were later superseded, rating overrides, time to decision by rating, the agent's reviews and agreement, quality-review outcomes, who decided, and how quickly applicants answered requests.

Compliance metrics page with decision metrics for the last 30 days
Compliance metrics for your KYB decisions.