KYC/KYB Criteria — The Criterion as a Versioned Asset

In a regulator's inspection, the painful question is not "did the AI read the document?" — it is "which exact criterion text was in force for January's analysis, and who answered for it?". In DATTA, the compliance criterion is a versioned asset: a business rule written in plain language by the specialist themselves, with an owner, a version and a change history. Changing a criterion stops being an IT ticket with a multi-week turnaround — it is the compliance manager editing a text and saving.

Owner, version and history

Each criterion on the Regras de Triagem (screening rules) panel shows three pieces of information that underpin traceability:

When you save an edit, the version in force is snapshotted into the history in the same transaction: if the snapshot fails, the edit does not happen. No version is ever lost along the way. The "Change reason" field is optional and is recorded together with the snapshot.

The platform also exposes the history for integration: you can list all versions of a criterion and retrieve the exact text of a specific version — the direct answer to "which text was in force for January's analysis?". See the API reference.

Applied version on the report

Every screening analysis records the criterion version applied (the regraVersao field on the report). Months later, the report lets you reconstruct the whole decision: which text was in force on that date, with the attached evidence and — in the PJ onboarding flow — who decided based on it.

Initial KYB criteria catalog

The file scripts/criterios-kyb-exemplo.json ships 15 criteria organized into four blocks:

• Completeness — the dossier has what it must have;
• Ownership and beneficial owner — the participation chain and who really controls the company;
• Powers and representation — who may sign on the company's behalf;
• Cross-checks — signals that only appear when entities are compared against each other.

They are user data, not factory content: load them through the screening rules panel or through the API (one object per criterion). The platform never seeds them automatically — so a criterion an institution deliberately removed does not come back on its own at the next update.

Principles embedded in the texts

The three principles below are already written into the sample criteria and can be edited by each institution:

• Absence is insufficiency. A criterion that depends on missing data produces an anomaly for insufficiency — never "compliant by omission".
• Computed numbers are facts. The ultimate beneficial owner computed by the platform arrives ready for the criterion; the text never asks the model to recompute the percentage.
• A cross-check never rejects on its own. A link obtained through probabilistic matching (name, partial CPF) flags the finding with its strength and origin, for human decision. The shared-attributes criterion (address/phone/accountant) carries the explicit warning: a shared address is also the reality of collective housing — it is an indication, not a verdict, and the threshold belongs to each institution's policy.

Good practices

1. Set the owner of every criterion. That is the person the regulator will ask; leaving it blank hands the question to whoever is in the room.
2. Use the reason when you change something. A "threshold adjusted after policy X review" is gold during an inspection — and costs ten seconds to write.
3. Pick the right scope. Criteria that depend on the whole dossier (completeness, sums of ownership percentages) use GLOBAL scope; pointwise ones use LOCAL. The sample catalog ships calibrated that way.

Learn more

• AI-generated screening rules — when the idea for a criterion still needs to become text.
• Validating rule references — how to check that the cited legal provision actually exists.
• PJ onboarding flow — where the criteria are applied in practice.