Corporate Onboarding — End-to-End BPMN Flow
Approving a legal entity usually turns into a patchwork of spreadsheets, emails and screenshots: a document is missing, nobody knows who is behind the company, and the decision leaves no record. In DATTA, corporate (PJ) onboarding is an executable BPMN process that takes each CNPJ from dossier arrival to a recorded human decision — with no automatic approval anywhere along the way.
The seed model is onboarding-pj-kyb.bpmn, versioned alongside the platform's other models and orchestrated by the BPM Engine. Each instance is born with the business key = CNPJ of the company under review and moves through completeness screening, ultimate beneficial owner (UBO) resolution, corporate structure analysis and the analyst's decision.
The flow on one page
Dossier received
▼
[Completeness screening] criteria KYB-COMP-1..3
▼
<Dossier complete?>
├─ CONFORME ───────────────────────────────┐
└─ default → [Request documents] │
→ (waits "documentos-recebidos") ─────┘ ← completeness loop
▼
[Ultimate beneficial owner resolution] datta:servico="ubo"
▼
[Corporate structure analysis & cross-checks] KYB-SOC-*, KYB-POD-*, KYB-CRUZ-*
▼
<Risk routing>
├─ all clear → [Analyst decision — simplified track]
└─ default → [Analyst decision — enhanced review]
▼
<Decision> → approved | rejected | back to completeness loopThe completeness loop: the process waits for the document on its own
When completeness screening fails the dossier, the flow opens the human task Request documents and then waits.
When the supplementary documents are uploaded through the Upload screen — with the same target CNPJ as the dossier — the platform automatically publishes the documentos-recebidos message, correlated to the CNPJ, at the end of the batch. The instance wakes up on its own and re-runs completeness screening. No manual "resume process" step is needed.
The UBO step is a service, not a screening
The Ultimate beneficial owner resolution task is a service task (datta:servico="ubo"): instead of running criteria-based screening, the engine calls the graph query that materializes the corporate chain from Receita and CVM (cross-link) and runs the recursive percentage traversal.
The result lands on the instance as scalar variables, ready for the gateways to decide:
| Variable | Meaning |
|---|---|
uboBeneficiarios | natural persons found at the end of the chain |
uboAcimaThreshold | how many exceed the threshold (25% — BCB Circular 3,978) |
uboAtingiuThreshold | true if any exceeds it |
uboDivergencias | divergences between computed and declared |
uboCaminhosDesconhecidos | paths with unidentifiable percentage |
uboTruncado | true if the traversal hit the path cap |
uboTemBaseNegativa / uboVinculosBaseNegativa | links to sanctions/negative bases |
uboResumo | summarized report (JSON) for display |
Risk routing: when in doubt, the case goes up
The simplified track is taken only when all conditions hold at the same time:
- corporate phase
CONFORME; - no beneficiary above the threshold;
- no link to a negative base;
- zero divergences between computed and declared;
- no critical anomaly.
Any other scenario falls into enhanced review — the gateway's default path. When in doubt, the case goes up, never down.
A human decision, always recorded
Both tracks end in a human task with a mandatory form:
- Decision —
aprovar(approve),rejeitar(reject) orpedir_documento(request document); - Reason — mandatory free text.
The simplified track is a queue with a pre-filled recommendation, not an approval shortcut: the analyst decides on both tracks, and the record keeps who decided, when and why — together with the criterion and the criterion version applied in screening (see KYC/KYB Criteria).
Choosing pedir_documento — or any decision other than approve/reject — sends the case back to the completeness loop.
Who can do what
| Action | Permission |
|---|---|
| View instances and timeline | BPMN_VIEW |
| Complete the decision tasks | BPMN_EXECUTE |
| Query UBO/dossier on the graph | KYB_VIEW |
| Publish/edit the model | BPMN_DEPLOY |
The documentos-recebidos notification triggered by the upload travels through the platform's internal channel between services (with a service token) — it does not depend on an open user session.
Publishing the model
The seed model is published like any other:
- Import the file in the BPMN Modeler screen and publish the version. The platform also exposes endpoints to import and publish models — see the API reference.
- If you want every new
:Empresain the dossier context to open an instance automatically, enable the model's auto-start. - Check that the context declared in the model (
datta:contexto="OnboardingPJ") matches the name of the dossier context registered under — that match is what ties the process to the right data.