Customer register and customer file

The customer register answers “who are our customers, and where does each one stand”. The customer file answers “who is this person, what do we know, and how do we know it”. Neither screen computes anything: every value is read from the place that decided it.

Who may open it: Maker, Checker, Approver, Compliance Officer, Head of Compliance and Internal Audit (read). Risk Manager and System Admin do not open customer files.

Customer register

One row per customer: reference, name, full identity number, risk level, review date, restriction status, screening status and how long evidence must be kept.
Summary figures at the top: customers in the book, high-risk customers, overdue reviews, customers under restriction, and customers whose evidence is still under retention.
Search and filters narrow the list; the count above the table is what remains.
Five working columns open by default; last review, occupation, screening, retention and account status can be added.
Each row links to open work on that customer — screening, review, restriction, risk adjustment, letters — only where there is something to open and your role can open it.

Customer file

The file opens on the person’s name, identity number, customer code and the work still open on them. Seven tabs follow the order officers use:

Identification — the particulars as received.
Identity proofing — document images, face images, liveness, face match and each item checked. See Identity proofing.
Screening and PEP status.
Changes from review — what each Re-KYC changed.
Suitability.
Documents.
Trail — every action on this customer, in time order, with who, which role, what and the detail.

A comments panel on the right takes notes and attachments. Every field is shown in full to everyone who can open the file — no masking, no reveal step, no reason to type — because each of these roles works as the institution’s data controller. A mandatory field that the source system did not send is shown as not sent; the screen never fills it in or guesses.

Suitability

The suitability tab is the one place in the file where data is recorded.

The Maker records the knowledge assessment, the suitability questionnaire and the financial figures, attaches the evidence and presses Send to reviewer.
The Checker approves or returns it on the Check and confirm screen.
The system computes the investor type, the knowledge result and the suitability score. The thresholds sit in a signed register.

Three axes (DA Dealer)

A dealer customer carries three separate, separately dated classifications: the SEC investor class, the AML risk rating and the association withdrawal class (S, M or L). None is computed from another. The withdrawal-class record keeps the evidence, the ground relied on, the officer and the guideline clause, so every limit traces back to its rule. A move from S or M to L is computed from the monthly trading data and confirmed by an officer — never automatic.

For a dealer, a KYT tab shows the on-chain risk results received from Trading Core — address, transaction hash, chain and asset, score, category and verdict — beside the KYC data and the institution’s own blocklist. CDD Core does not call the analytics provider again.

What the system does or refuses

Customer data changes only through its own routes: a Re-KYC review, a risk adjustment or a restriction, each with its own sign-off.
Nothing is invented. A value the source did not send stays visibly empty.
The trail tab is read from the system’s action log, which no one can edit.

Customer register and customer file