For years, Brazilian banks treated data quality as an internal engineering concern. That era is over. On November 28, 2025, the Conselho Monetário Nacional and the Banco Central do Brasil jointly issued Resolução Conjunta nº 18, a policy that turns data quality into a supervised, board-level obligation.
It took effect on January 1, 2026, and full compliance is due by December 31, 2026. When the industry asked for more time, the central bank said no.
So what does the regulation actually demand, and how do you prove your bank meets it? The answer comes down to twelve named dimensions of quality and your ability to show, on demand, that your data satisfies each one.
Resolução 18 turns a global principle into a Brazilian obligation.
The resolution sets a policy for the quality of information that regulated institutions submit to the central bank. It reaches further than most compliance teams expect. The scope covers operational reports, credit-system (SCR) data, Open Finance data, and customer fee schedules, spanning quantitative and qualitative data alike.
Three requirements give the rule teeth.
First, Article 5 requires every institution to designate a director who answers to the Banco Central for compliance with the resolution. Accountability doesn't stop there. Article 3 requires your policy to set deadlines for the directors of the areas that produce and provide the information, so they fix what monitoring finds. And Article 7 forbids delegating any of the board's or executive board's duties under this resolution: accountability cannot be pushed down.
Second, institutions must run continuous monitoring, including quality tests, and correct problems as they surface.
Third, the regulator holds the enforcement end. Article 10 gives the Banco Central real leverage: it can set the minimum quality a submission must clear, reject what misses, and order a resubmission. It can also define the specific tests you run before filing. Article 3 then puts those tests on you, executed against your own data, ahead of the submission, and reconciled to your internal systems.
"During the crisis it became evident that financial institutions couldn't aggregate risk data with sufficient speed, precision and comprehensiveness to support decision-making during stress periods," noted Fábio Lacerda, a risk management partner at KPMG (translated from the original Portuguese).
That diagnosis is exactly where this rule comes from.
This is BCBS 239, and a decade of evidence shows how hard it is.
Resolução 18 carries the DNA of BCBS 239, the Basel Committee's Principles for effective risk data aggregation and risk reporting — extending Basel's data-quality logic beyond risk data to the full range of information Brazilian institutions report.
Published in January 2013, BCBS 239 was one of the clearest lessons of the 2008 financial crisis: banks could not aggregate their risk exposures fast enough or accurately enough when it mattered most. Its 14 principles, 11 for banks and 3 for their supervisors, have applied to global systemically important banks since January 2016.
Here is the uncomfortable part. More than a decade after that deadline, only 2 of 31 assessed G-SIBs are fully compliant with the principles, and not a single principle has been fully implemented across every bank (BIS, November 2023). The Basel Committee named the obstacle plainly: underfunded programs, thin board attention, and fragmented legacy IT systems.
That track record should reframe how Brazilian institutions read their own December 2026 deadline. If banks with a ten-year head start and billion-dollar budgets have struggled, treating Resolução 18 as a last-quarter documentation exercise is a serious miscalculation.
There's a tell worth noticing, too: Brazil elevated traceability to a named, first-class dimension. That's precisely the lineage capability BCBS 239 tucks inside its data-architecture principle, and precisely what legacy-heavy banks find hardest to prove.
The twelve dimensions Brazilian banks must now prove.
Resolução 18 makes explicit what BCBS 239 embeds in its aggregation and reporting principles. Where the Basel text describes capabilities, the Brazilian rule enumerates twelve measurable dimensions of quality. Each one maps back to a BCBS 239 principle, which is why teams that have studied Basel are not starting from zero.
The table shows each dimension's closest BCBS 239 principle, not a strict one-to-one — several map to more than one. Relevância, for example, sits under Principle 8 (comprehensiveness) but also overlaps Principle 9's call for information tailored to its recipients.
The list is coherent, but it raises the operational question every governance lead is now asking. How do you prove, dimension by dimension, that your data holds up, and keep proving it every day between now and the deadline?
If you want to see how banks structure this dimension-by-dimension, our walkthrough of closing the BCBS 239 data-quality gap covers the controls end to end.
How data teams can cover all twelve dimensions.
This is where the regulation stops being a legal document and becomes a data-engineering program. But start with a distinction that will save you a quarter: the twelve dimensions are not twelve measurement problems.
Nine of them become a rule running on the data, testable on every load and evidenced on demand. Three are obligations about how your institution publishes, presents and adapts information: governance and report design, not checks.
So how can we, as data teams, turn the measurable ones into continuous, evidenced checks?
By treating quality as living checks that run on every load, not as a static policy that lives in a slide deck.
At Soda, we've seen governance leads collapse the measurable dimensions into a set of automated checks that run against production data continuously.
Here are the nine you can automate. Each becomes something you can measure, alert on, and evidence for a supervisor.
Acessibilidade is about the conditions under which users obtain information: clear indication of where it is published, how to raise a request, what deadlines apply, and, in the text's own words, assured special treatment for persons with disabilities. That is publication and service design.
Clareza is concise presentation that the intended reader can actually follow. That is report design.
Adaptabilidade is the capacity to generate information in formats that meet varied demands, including ones you do not report periodically, ones arising from foreseen regulatory change, and ones that land during a crisis. That is architecture and operating model: what your reporting stack can be asked for on short notice, by someone who did not warn you.
A data-quality platform can evidence that the numbers underneath these three are sound. It cannot decide what you publish, to whom, in what form, or whether it was worth publishing.
How Soda fits
Three of Soda's capabilities do most of the work on the nine measurable dimensions.
Data contracts let governance and engineering co-author what "good" means for a dataset, in a versioned artifact that is reviewed like code. That is where accuracy, completeness and consistency expectations get written down and enforced in the pipeline, and where the definitional stability comparability depends on is recorded rather than remembered.
Data observability runs those expectations continuously, with anomaly detection that learns each dataset's own baseline instead of firing on a fixed threshold, and alerting tuned to cut false positives rather than pile them up.
The Diagnostics Warehouse evaluates the checks, stores the resulting metadata, and moves failed rows into a designated schema inside your own warehouse. Nothing leaves your environment. That is the evidence half of traceability: for any regulated dataset and any date a supervisor names, the check that ran, the result it returned, and the rows that failed.
On lineage, be precise about what you actually have. Rastreabilidade asks you to trace information from its origin through to delivery to the end user. A check history proves what was tested and what failed; it does not by itself draw the path the data took to get there. That path lives in your architecture and, for most banks, in a catalog.
Soda integrates with the main catalog and governance tools: Alation, Atlan, Collibra, and others. It publishes check results and quality scores into them, so the quality signal appears on the lineage your catalog already maintains.
A supervisor tests three things for every dimension.
For each of the twelve dimensions, a supervisor must be ready to see three things: the check that ran, the result it returned, and the record of what failed and when.
It helps to picture the exam before you sit it. The Banco Central can set the minimum quality level a submission must clear to be accepted, define the specific tests you have to run before filing, reject what misses, and order a corrected resubmission.
And the evidence has a shelf life: Article 11 requires you to keep the policy documentation and the quality report available to the regulator for at least five years. That turns the evidence package into the real deliverable, and into something you have to be able to reproduce years after the fact.
The distinction that separates a passing program from a failing one is timing. A team that can produce that evidence on demand — for any regulated dataset, on any date the regulator names — passes. A team that has to reconstruct it after the request, assembling months-old runs from logs and memory, does not.
This is why accountability reaches into the processes that produce the data, not just the filing: the designated director is the one who has to stand behind that evidence when the Banco Central asks for it.
What to do before December 31, 2026.
The deadline is closer than the calendar suggests, because covering twelve dimensions across every regulated dataset is a program, not a project. Here are the steps that matter most, ordered by urgency.
Name the responsible director now. The regulation requires it, and the appointment shapes accountability for everything that follows. Do this first.
Inventory your regulated data against the twelve dimensions. Map operational, SCR, Open Finance, and fee data to the dimensions, and mark where you have no way to measure a given dimension today. Those gaps are your work list. Sequence by regulatory exposure, not convenience. The reports the Banco Central can reject outright, SCR submissions and operational reports, earn checks first. Fund the traceability work early; it's the dimension banks consistently find hardest to evidence.
Automate continuous quality tests. Convert the nine measurable dimensions into checks that run on every data load, so quality is evidenced by default rather than assembled by hand before an audit.
Stand up the semiannual report now. Article 3 requires a consolidated report on your information-quality processes every six months, detailing the irregularities found, including the ones the Banco Central pointed out, and the remediation already taken and still in flight. It goes to the board or executive board, to the audit committee where one exists, to internal and independent audit, and to the Banco Central when requested.
Build the audit trail as you go. Store the results of every check where your evidence lives in your environment, so traceability is a byproduct of monitoring, not a scramble.
Do not treat this as a one-time certification. A dashboard that was green in November proves nothing about the data a supervisor tests in March. And do not wait for the RDARR-style financial-services controls to be someone else's problem; the director you appoint owns them.
Brazil is not an outlier. It's the pattern.
Resolução 18 fits a clear global direction. In May 2024, the European Central Bank published its Guide on effective risk data aggregation and risk reporting, tightening supervisory expectations for the banks it oversees. Brazil is now doing the same, and other jurisdictions are watching both.
The shared message from supervisors is that BCBS 239 has moved from principle to enforceable, tested operational requirement.
For data leaders, that shift is the real headline — and one they already feel: 94% of banking data leaders name the accuracy and reliability of data a priority (Deloitte, 2024).
Regulatory data quality is no longer a periodic reporting exercise handled by a compliance team. It is a continuous engineering capability that boards are accountable for, measured against dimensions a regulator can test at any time.
The banks that treat the December 2026 deadline as the start of a permanent capability, rather than a one-off filing, are the ones that won't be repeating this exercise for the next regulation.
This is the kind of obligation that should run continuously, not get assembled in a scramble before an audit. That's the shift Soda is built for: the measurable dimensions become automated data contracts and monitors that evidence themselves on every load, with a failed-record trail a supervisor can inspect.
If you're turning Resolução 18 into controls, explore our data contract templates or book a demo to see dimension-by-dimension coverage in your own environment.
Frequently asked questions
What is Resolução Conjunta nº 18?
It is a joint policy from Brazil's Conselho Monetário Nacional and Banco Central do Brasil, issued November 28, 2025 and effective January 1, 2026. It requires regulated financial institutions to ensure the quality of information submitted to the central bank across 12 defined dimensions, with full compliance due by December 31, 2026.
When is the Resolução 18 compliance deadline, and can it be extended?
Full compliance is due December 31, 2026. The central bank has already declined to postpone it. Institutions must have governance, continuous monitoring, correction mechanisms, and a designated responsible director in place by that date, and be ready for the regulator's own tests.
Does a data quality platform make my bank BCBS 239 compliant?
No tool grants compliance on its own; that comes from governance, accountability, and supervisory review. And it does not cover all twelve: three of the dimensions (accessibility, clarity, adaptability) are obligations about how you publish, present and adapt information, not properties of a dataset. What a platform does is make the other nine measurable and continuously evidenced, so you can prove quality on demand instead of assembling it by hand before an audit.









