If you build payment, banking or on-ramp software that touches Brazil, a requirement has probably landed in your backlog this month: "flag crypto counterparties that aren't authorised by the Central Bank."

The trigger is Article 91 of Resolution BCB 520, as amended by Resolution BCB 589. From 6 November 2026, financial institutions, payment institutions and other institutions authorised by Banco Central do Brasil (BCB) may not carry out or enable virtual-asset market operations with counterparties that provide virtual-asset services and are not authorised by the BCB, except in the forms the resolution expressly allows. The rule names trading, intermediation and custody, FX, and opening and maintaining payment accounts used to enable those operations.

Whether a given relationship is caught by that rule is a legal question. This post is about the engineering underneath it: how do you build a status check that produces evidence your compliance team can actually rely on? We'll use the BCB's own open data, and I'll show the traps I hit while building VASP Tracker's Brazil pipeline.

The Source: BCB's Olinda OData Service

The BCB publishes its authorisation-process data on its open-data portal (licensed ODbL) and serves it through an OData API, Processos_Autorizacao, with two functions:

Crypto firms applying under the new regime show up with SegmentoPretendido = "Sociedade Prestadora de Serviços de Ativos Virtuais" (SPSAV). At the 30 September 2026 reference date, the feed listed 184 open processes across all segments, 7 of them SPSAV.

Design Principle: Store Evidence, Not Booleans

The tempting schema is is_authorised: bool. Don't. For a rule like this, what your compliance team needs is what the regulator's data said, as of when, and where it came from. So the check returns an evidence record:

• state: open_process or not_found (and, once your source covers it, authorised)
• as_of: the reference date of the data, not the timestamp of your API call
• process, segment, situacao: the BCB's own identifiers and labels, verbatim

Keep open_process and authorised as separate states, and keep the mapping from state to business action ("block", "review", "allow") in configuration owned by compliance, not in code. This matters here in particular. The original text of Article 91 covered providers "not authorised or in the process of authorisation". The version amended by Resolution 589 refers only to providers "not authorised". How "in process" should be treated is exactly the kind of call that belongs to your legal team, and it should be changeable without a deploy.

The Code

Standard library only, Python 3.10+.

import json, re, time, urllib.parse, urllib.request
from dataclasses import dataclass, asdict
from datetime import datetime

BASE = "https://olinda.bcb.gov.br/olinda/servico/Processos_Autorizacao/versao/v1/odata"
SPSAV = "Sociedade Prestadora de Serviços de Ativos Virtuais"

def odata(path: str, params: dict) -> list:
    qs = urllib.parse.urlencode(params, safe="@'$()")
    url = f"{BASE}/{path}?{qs}"
    for attempt in range(3):
        try:
            req = urllib.request.Request(url, headers={"User-Agent": "counterparty-check/0.1"})
            with urllib.request.urlopen(req, timeout=60) as r:
                return json.loads(r.read())["value"]
        except Exception:
            if attempt == 2:
                raise
            time.sleep(2 ** attempt)

def snapshot(month: str) -> tuple[str, list]:
    """Open authorisation processes for a reference month ('YYYY-MM').
    Returns (reference date the API actually served, rows)."""
    rows = odata("ProcessosAutorizacaoFuncionamentoEmAberto(dataBase=@dataBase)",
                 {"@dataBase": f"'{month}'", "$format": "json", "$top": "20000"})
    served = {r["DataBase"] for r in rows}
    if len(served) != 1:
        raise ValueError(f"mixed reference dates: {served}")
    as_of = datetime.strptime(served.pop(), "%d/%m/%Y").date().isoformat()
    if not as_of.startswith(month):
        raise ValueError(f"asked for {month}, API served {as_of}: snapshot not published yet?")
    return as_of, rows

def root(cnpj: str) -> str:
    d = re.sub(r"\D", "", cnpj or "")
    return d[:8] if len(d) >= 8 else ""

@dataclass
class Evidence:
    cnpj_root: str
    state: str          # "open_process" | "not_found"
    as_of: str          # reference date of the data, not the date you ran the check
    process: int | None = None
    segment: str | None = None
    situacao: str | None = None
    name: str | None = None

def check(roots: list[str], month: str) -> list[Evidence]:
    as_of, rows = snapshot(month)
    by_root = {}
    for r in rows:
        if root(r["CNPJInteressado"]):
            by_root.setdefault(root(r["CNPJInteressado"]), []).append(r)
    out = []
    for cr in roots:
        hits = [r for r in by_root.get(cr, []) if r["SegmentoPretendido"] == SPSAV]
        if not hits:
            out.append(Evidence(cr, "not_found", as_of))
            continue
        for h in hits:
            sit = odata("SituacaoProcessosAutorizacao(numeroPE=@numeroPE)",
                        {"@numeroPE": str(h["NumeroPE"]), "$format": "json"})
            out.append(Evidence(cr, "open_process", as_of, h["NumeroPE"], h["SegmentoPretendido"],
                                sit[0]["Situacao"] if sit else None,
                                " ".join(h["NomeInteressado"].split())))
    return out

if __name__ == "__main__":
    # one CNPJ root with an open SPSAV process at 30/09/2026, one not in that snapshot
    for e in check(["34882109", "18213434"], "2026-09"):
        print(json.dumps(asdict(e), ensure_ascii=False))
    try:
        snapshot("2026-10")
    except ValueError as err:
        print("guard:", err)

Output on 22 October 2026:

{"cnpj_root": "34882109", "state": "open_process", "as_of": "2026-09-30", "process": 315453, "segment": "Sociedade Prestadora de Serviços de Ativos Virtuais", "situacao": "Em Exame", "name": "TRANSFERO SOCIEDADE PRESTADORA DE SERVICOS DE ATIVOS VIRTUAIS (SPSAV) LTDA."}
{"cnpj_root": "18213434", "state": "not_found", "as_of": "2026-09-30", "process": null, "segment": null, "situacao": null, "name": null}
guard: asked for 2026-10, API served 2026-09-30: snapshot not published yet?

(Em Exame means "under examination".)

Five Traps in the Feed

1. Asking for a month that doesn't exist yet still returns data. Requesting dataBase='2026-10' (no October snapshot published yet) returned rows labelled 30/09/2026. It wasn't even the same set: 186 rows, against 184 for an explicit '2026-09' request. If you key your storage on the month you asked for, you'll silently save September's data as October's. Always key snapshots on the DataBase value in the response, and reject mismatches, which is what the guard in snapshot() does.

2. The CNPJ is truncated, and often missing. CNPJInteressado holds only the 8-digit company root (for example 34.882.109), not the full 14-digit CNPJ. In the 186-row response, 60 rows had no CNPJ at all. Match on the root, and treat a missing root as "cannot match", not "no match".

3. One brand, many legal entities. Platforms in Brazil often run several entities: an SPSAV, a securities broker, a payment institution. In our Brazil dataset, one large exchange maps to three CNPJ roots. Your counterparty master data has to resolve brand to entity to root before any API call means anything.

4. Fields you'd want are mostly empty. DataProtocolo (filing date) was filled in for 1 of 186 rows, so you can't use this feed to tell whether a firm filed before 30 October. SegmentoPretendido was blank on 3 rows. Names are free text with stray double spaces. Normalise before you display or fuzzy-match.

5. History has holes. The August 2024 reference date answers HTTP 500 for a full read on our side. Build retries, log gaps explicitly, and don't backfill them with neighbouring months.

The Timing Problem

The feed is monthly. The deadline for existing providers to file phase 1 of their application is 30 October 2026 (Resolution 520, art. 88; Normative Instruction 704, art. 9). The restriction on regulated institutions starts 6 November 2026. The first reference date that can reflect filings made up to the deadline is 31 October 2026, and it will only be visible once the BCB publishes it.

So for the first stretch of November, a not_found against the September snapshot tells you very little: the firm may have filed in October. Your check should surface as_of prominently, and your policy config should say what happens when the newest data predates the deadline. Firms that filed on time may keep operating while their process runs (art. 88, §6). Firms that didn't must stop within 30 days of the deadline (art. 88, §7).

Where to Go From Here

• Run the check daily, but persist only when DataBase changes. Hash each snapshot and diff the process lists month to month. A process disappearing from the "open" list is a signal to look up its outcome, not a verdict.
• For authorised status itself, take it from the BCB's authorisation data once SPSAVs start appearing there. As of the 30 September reference date, VASP Tracker found no SPSAV listed as authorised.
• If you'd rather start from a curated mapping, our Brazil open data publishes 170 tracked platforms with their legal entities, CNPJ roots, SPSAV process numbers and BCB status per reference date (CSV/JSON, CC BY 4.0). Use it as a starting point, and verify against the BCB before acting.

VASP Tracker is an independent project, not affiliated with Banco Central do Brasil or any regulator. This is an engineering write-up, not legal advice. How Article 91 applies to your institution is a question for your counsel and the BCB.

Sources

• Banco Central do Brasil, Resolução BCB nº 520 (10 Nov 2025), arts. 88 and 91: https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20BCB&numero=520
• Banco Central do Brasil, Resolução BCB nº 589 (23 Sep 2026), amending art. 91: https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20BCB&numero=589
• Banco Central do Brasil, Instrução Normativa BCB nº 704, art. 9: https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Instru%C3%A7%C3%A3o%20Normativa%20BCB&numero=704
• BCB open data portal, "Processos de autorização" (ODbL): https://dadosabertos.bcb.gov.br/dataset/processos-de-autorizacao
• BCB Olinda API documentation, Processos_Autorizacao v1: https://olinda.bcb.gov.br/olinda/servico/Processos_Autorizacao/versao/v1/documentacao
• VASP Tracker, Brazil open data (data dictionary and downloads): https://vasptracker.com/en/br/data/