PT EN
Back to site

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 loop

The 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:

VariableMeaning
uboBeneficiariosnatural persons found at the end of the chain
uboAcimaThresholdhow many exceed the threshold (25% — BCB Circular 3,978)
uboAtingiuThresholdtrue if any exceeds it
uboDivergenciasdivergences between computed and declared
uboCaminhosDesconhecidospaths with unidentifiable percentage
uboTruncadotrue if the traversal hit the path cap
uboTemBaseNegativa / uboVinculosBaseNegativalinks to sanctions/negative bases
uboResumosummarized 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:

  • Decisionaprovar (approve), rejeitar (reject) or pedir_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

ActionPermission
View instances and timelineBPMN_VIEW
Complete the decision tasksBPMN_EXECUTE
Query UBO/dossier on the graphKYB_VIEW
Publish/edit the modelBPMN_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:

  1. 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.
  2. If you want every new :Empresa in the dossier context to open an instance automatically, enable the model's auto-start.
  3. Check that the context declared in the model (datta:contexto="OnboardingPJ") matches the name of the dossier context registered under SistemaContextosGerenciar — that match is what ties the process to the right data.