Compliance Pendencies Panel
The panel (menu Investigation › Compliance Pendencies) gathers, on a single screen, everything that requires human action in the KYB vertical of the selected context — and tracks the treatment of each item through a BPM process, with decision, reason and audit trail.
It answers the daily question of a compliance desk: "what is pending today, across every company, and who is treating what?"
Where pendencies come from
| Source | What gets in | What does NOT |
|---|---|---|
| Certificates | Expired, about to expire (configurable alert window) and not verifiable (unreadable/missing date) | A valid certificate is not a pendency |
| Triage criteria | Every criterion with a non-compliant, anomaly or critical-anomaly result in the latest report | Compliant criteria and files not yet triaged |
The two sources are queried in parallel and degrade independently: if one is unavailable, the panel shows what it could gather and warns — by name — about what is missing.
Severity
- High — expired certificate or critical-anomaly criterion.
- Medium — certificate about to expire or non-compliant criterion.
- Attention — non-verifiable certificate (the system could not read the date: notably, that never becomes "valid" by omission).
Treatment is a BPM process
Each pendency can have its treatment opened with one click (Open treatment, requires the BPMN_EXECUTE permission). That creates an instance of the Compliance Pendency Treatment process in the platform's BPMN engine, with the pendency as the business key — the key by which the panel finds the treatment again every time it opens. The panel has no database of its own: the record IS the process.
The flow has three paths, all ending in a human decision with a mandatory reason:
- Regularise — the handler proves the regularisation by attaching the evidence reference (new certificate, document, correction).
- Accept the risk — requires a second approval level: the approver is not the proposer. Without explicit approval, the pendency returns to treatment.
- Escalate — goes up to the compliance committee, which decides between demanding regularisation or accepting the risk on behalf of the institution.
The design is deliberately conservative: if a decision arrives outside the expected domain, the process never closes on its own — it climbs a level or returns to treatment. Every task carries an SLA (datta:slaHoras), visible in the Process Monitor.
Screen actions
- Open treatment — creates the BPM instance (hidden once one exists).
- Follow — opens the instance in the Process Monitor, where the task is concluded with decision and reason.
- View file — opens the PJ Onboarding console on the pendency's company.
Requirements
- A context of type Registration File (KYC/KYB) registered.
- The Compliance Pendency Treatment model published in the BPMN Modeler. The seed file ships with the platform; an administrator imports and publishes it once through the Modeler screen.
- Permissions: viewing the panel requires the vertical's read permissions (
KYB_VIEW); opening a treatment requiresBPMN_EXECUTE; concluding tasks follows the BPMN engine's own rules.