Regulatory reports architecture
The two ways to run reporting to the Banco Central: an agent inside the VASP's infrastructure, or a model managed by Clav.
Two models, one engine
Clav generates, validates and sends the VASP’s regulatory reports, such as CCS and ACAM212, to the Banco Central. The VASP chooses where that work happens: inside its own infrastructure, through a Clav agent, or at Clav, in an environment isolated for that VASP alone.
Model A: agent
The agent runs in the VASP’s infrastructure. Customer personal data and the Sisbacen credential stay there, and Clav receives only metadata.
Model B: managed
Clav runs everything. Data arrives through an API or CSV and is kept in a database of the VASP’s own, encrypted with a key that belongs to it alone.
The generation engine and the input data format are the same in both models, so a VASP can start with one and move to the other later.
Model A: agent at the VASP
The Clav agent is installed in the VASP’s environment, which needs Kubernetes or Docker and a secrets vault. It reads data through local connectors (database, API or CSV), builds the file and sends it to the Banco Central.
Customer personal data never leaves the VASP, and neither does the Sisbacen credential. Clav receives only metadata, which feeds the status dashboard. In this model Clav does not process personal data, and the cloud due diligence is lighter.
When the Banco Central changes a report layout, Clav publishes a signed package and the agent applies the update.
Model B: managed by Clav
The VASP needs no infrastructure at all. Clav receives the data, generates the reports, sends them and applies layout changes with no work on the VASP’s side.
How data arrives
| Method | When to use it |
|---|---|
| API push | The main method. Each VASP gets its own client certificate, and the gateway identifies the VASP by that certificate. |
| Pull | When the VASP already exposes an API and agrees to open inbound access for Clav. |
| CSV upload | Through the dashboard or SFTP. Suited to small VASPs and as a fallback. |
Ingestion is idempotent. Each event carries an ID generated by the VASP, and resending the same event does not duplicate the record.
Isolation levels
| Level | How it works | When to use it |
|---|---|---|
| Database per VASP (default) | Its own database or instance, with its own role and KMS key | Standard plan for the managed model |
| Cloud account or project per VASP | Separate network, IAM and billing | Premium plan, for large VASPs or stricter due diligence |
Separate schemas inside a shared database are not offered, because that level of separation is not enough for personal data.
Security controls
Each VASP has its own cell: database, KMS key and secrets. The worker that processes a VASP’s reports assumes an IAM role that reaches only that cell’s resources, so a compromised worker cannot get to another VASP’s data.
CPF, CNPJ and name are encrypted field by field with the VASP’s key (envelope encryption). Dumps and backups hold only ciphertext. Searches and delta calculation use a blind index, an HMAC of the CPF computed with the VASP’s key, so they never need the plaintext value.
The Sisbacen password is also encrypted with the VASP’s key. Only the worker decrypts it, at the moment of submission.
By default, nobody at Clav has access to a VASP’s data. When access is needed, it is granted on demand (just in time), with approval and an audit trail.
Data stays in a Brazilian region. Clav keeps only what is needed to compute deltas, file corrections and meet legal deadlines, and follows a documented disposal policy.
Sisbacen credential
The Sisbacen manual expects each operator to use their own user. We recommend that the VASP create a user dedicated to the integration, under its own responsibility, which it can revoke at any time.
LGPD and procurement
In the managed model, Clav acts as processor of the personal data of the VASP’s customers. That calls for a processor agreement, a record of processing operations and an incident response plan for each VASP.
For the VASP, Clav becomes a relevant contracted cloud processing and storage service. Due diligence for this kind of contract usually asks for a SOC 2 or ISO 27001 report, periodic pentests and clauses that guarantee the Banco Central access to the data.
Comparison
| Criterion | Model A: agent | Model B: managed |
|---|---|---|
| VASP infrastructure | Kubernetes or Docker, secrets vault | None |
| Personal data leaves the VASP | No | Yes, encrypted with the VASP’s key |
| Sisbacen credential | Stays at the VASP | Stays at Clav, encrypted with the VASP’s key |
| Clav’s role under LGPD | Does not process personal data | Processor |
| Cloud due diligence | Light, metadata only | Full, relevant service |
| Integration effort | Local connectors (database, API or CSV) | API push or CSV |
| Layout updates | Signed package applied by the agent | Transparent |
| Status visibility | Clav dashboard | Clav dashboard |
| Best fit | VASPs with an infrastructure team or a policy against sharing data | Small VASPs or VASPs without an infrastructure team |
Which one to choose
Rule of thumb
If the VASP has an infrastructure team or an internal restriction on sharing customer data, model A fits best. If it has no infrastructure and would rather outsource the operation, model B covers it without asking anything of the VASP’s side.