BancosBrasileiros: a daily-updated registry of Brazilian financial institutions

What the dataset is, and how it stays current

BancosBrasileiros is a comprehensive database containing information on over 400 registered Brazilian financial institutions, and the data is automatically updated daily from official sources using the project's MergeTool.

That combination of scope and freshness is the whole value. The alternative to this dataset is scraping the regulator's own published lists, and for a Brazilian financial institution that means working with the Banco Central do Brasil and the STR, the Sistema de Transferências de Reservas, and keeping up with whatever format the regulator publishes this month. The list here is assembled by a separate tool, the MergeTool repository, which is the part that does the fetching, reconciling and merging, and the output is committed into this repository as data files.

The daily cadence is visible in the repository itself, with a GitHub Actions workflow named daily-updates, and the release history shows it: v6.3.73 on 2026-10-19, v6.3.72 on 2026-10-18 and v6.3.71 on 2026-10-17, one release per day with a patch number that tracks the day. The last push to the repository was on 2026-10-22.

So the operational model is a data pipeline that produces a new version of the database every day, and the version number tells you how far along it is. A consumer that pins a version gets a snapshot, and a consumer that follows main gets today's regulators.

The project also runs a link checker as a separate workflow, with a.lycheeignore file for the URLs to skip, which is a sensible thing to do for a dataset where one of the fields is an institution website URL that will eventually go dead.

The schema, and what the Brazilian regulatory vocabulary means

The field list is the part that matters for anyone using the data, because it is written in Brazilian regulatory terms rather than generic ones.

The identifiers come first. COMPE is the bank code, the clearing system code, three digits. ISPB is the Brazilian Payment System ID, eight digits. Document is the CNPJ, the company registration number, given as 14 numbers or 18 digits formatted. LongName and ShortName are the official and abbreviated institution names, as registered with BACEN and STR.

Then the classification fields. Network is the connection network type, one of RSFN, Internet, or null. Type is the institution type, commercial, multiple, savings, or null. PixType is the PIX or SPI participation type, DRCT for Direct or INDR for Indirect, or null.

The participation flags are a long list of booleans, and they are the fields that make this useful beyond an address book. Charge indicates support for charge operations. CreditDocument indicates support for TED operations. LegalCheque records participation in Cheque Legal. DetectaFlow records participation in Detecta Flow. PCR and PCRP record participation in those two schemes. And SalaryPortability is a three-state field, either Banco folha e Destinatário meaning both payroll payment and receiving, Destinatário meaning receive only, or null.

The commercial side of the record is short. Products is the list of offered financial products, in Portuguese, which matters if you are matching on product names. Url is the official website and LogoUrl is the institution logo image, either a URL or null.

And the dates close it: DateOperationStarted for when commercial operations began, DatePixStarted for when PIX operations started for PIX participants only, DateRegistered for when the database entry was created, and DateUpdated for the last update of the entry.

Five formats, schemas and eleven class definitions

The data is published in five formats and the reason is spelled out for each one.

CSV is for spreadsheet applications and data analysis. JSON is for web applications and APIs. Markdown is for documentation and GitHub projects. SQL is for database implementations, and XML is for legacy systems and specific applications. Those five cover the range from a data analyst opening a file to a legacy system that only speaks XML, and choosing the format by consumer rather than by preference is a good decision for a dataset that gets embedded in other people's projects.

The schemas are published alongside the data, in a schemas/ directory, with ready-to-use definitions in JSON Schema, SQL Schema and XML Schema, so a consumer can validate an input or an output rather than trusting the field names.

Then there are the class definitions, and this is the part that saves real work. Pre-built definitions are provided in C#, Dart, Go, Java, JavaScript, Kotlin, PHP, Python, Rust and TypeScript, each in its own file, and the point of shipping them is that nobody has to transcribe twenty-six fields into their own model by hand and get a typo in the date format.

The implementation examples go further, with practical examples in the examples/ directory for Dart, .NET and C#, EmberJS and PHP. Those are complete worked examples rather than schema definitions, and they are the fastest way to see how a consumer is expected to load the data and use it.

The packaging is a further sign of how broad the consumer base is. The repository tree carries a setup.py and pyproject.toml for Python, a package.json for JavaScript with the main entry point at bancos.json, a Cargo.toml for Rust, a composer.json for PHP, a pubspec.yaml for Dart, and a BancosBrasileiros.nuspec for NuGet. The Python package finds its packages under src/ with package_dir set to src, and the Rust manifest is edition 2021 with a MIT OR Apache-2.0 licence.

The licence metadata disagrees with itself, and that is worth knowing

The licence situation in this repository is a small case study in how metadata drifts, and it is worth flagging for anyone building on the data.

The licence field in the repository metadata says Unlicense, which is a public-domain dedication with no requirements. The Python packaging is different: setup.py declares the classifier License:: OSI Approved:: MIT License, and the long description is read from README.md. The JavaScript packaging in package.json says license UNLICENSED, which in npm means the package is private and unpublished, with a version of 6.3.0 and a main entry point of bancos.json.

The Rust manifest says MIT OR Apache-2.0, a third answer. And the repository tree carries both a LICENSE file and a BancosBrasileiros.nuspec.

The likely explanation is that the Unlicense is the author's intent for the data, and that the per-language packaging files were written at different times with different defaults, and that the Rust Cargo.toml is a template that was never fully filled in, since it still carries a repository field of https://github.com/username/repository and a comment saying to add any crate dependencies here.

For a consumer this matters in a specific way. The Unlicense places the data in the public domain, which is the most permissive arrangement available and means you can use it without attribution. MIT and Apache-2.0 are permissive but not the same, and if you have a policy that checks the licence of a dependency, three different answers across the packaging files of one repository is a question your legal team will ask. The practical resolution is to ask the author or to check the LICENSE file in the repository root, which is the file the documentation points to.

That is worth doing anyway for any dataset you plan to redistribute, since the data is derived from official sources whose own terms apply to republication of the underlying records.

Where BancosBrasileiros is the wrong tool

The first limit is the country. Everything in this dataset is Brazilian, from the clearing system codes to the participation flags for Brazilian payment schemes, and a team outside Brazil has no use for it. That is obvious and worth saying only because a registry like this looks general at a glance.

The second is that it identifies institutions, it does not describe accounts or payments. There is no branch network here, no account number format, no routing detail beyond the bank code, and no information about products beyond a list of names in Portuguese. If you need to validate a Pix participant, a TED beneficiary or a salary portability arrangement, some fields here help and the rest of the work is elsewhere.

The third is the daily churn. A release per day is excellent for freshness and awkward for reproducibility, because a version pinned in a lockfile becomes stale within a day and a deployment that fetches the latest at build time changes its data without a code change. The version numbers are patch releases with a monotonically increasing counter, so there is no way to ask for the dataset as it was on a particular date without finding that specific tag.

The fourth is that the data is a snapshot of a regulator's view. The names are as registered with BACEN and STR, the participation flags are as the institution reported them, and a field can legitimately be null because the regulator has not published it. A null PixType or a null Network is not a bug in the pipeline, and code that treats null as an error will produce noisy failures.

And the fifth is the field naming itself. The Products list is in Portuguese, the type values are in Portuguese or in the scheme's own vocabulary, and the boolean flags are named after Brazilian instruments. A team outside the Brazilian payments domain will need a translation layer, and a team inside it will find that the vocabulary matches the regulator's documents, which is a benefit for correctness and a cost for portability.

Editorial conclusion

BancosBrasileiros is worth depending on if you build anything that has to identify a Brazilian bank, because the registry is refreshed daily from official sources rather than maintained by hand, because the same content is published in five formats so you can take the CSV for a spreadsheet or the SQL for a database without writing a parser, and because the typed class definitions in ten languages mean you are not hand-transcribing a schema. It is the wrong tool if you need payment institution data outside Brazil, and the wrong tool if you need banking data that is not about institutions. Before you adopt it, check three things: which fields you actually need, because the schema is Brazilian regulatory vocabulary with a bank code, a payment system identifier, a company registration number and a set of participation flags for Pix, TED, Cheque Legal and salary portability, and only some of it applies to a given institution; that the licence is what you expect, because the licence field in the repository metadata says Unlicense while the Python packaging classifies it as the MIT licence and the JavaScript packaging says UNLICENSED, which are three different statements in one project; and that you pin a version rather than following the data, because the releases move daily, with v6.3.71, v6.3.72 and v6.3.73 published on consecutive days in October 2026, so the numbers change under you even when nothing about the code does.

Frequently asked questions

Official sources

1. guibranco/BancosBrasileiros on GitHub
2. License: Unlicense
3. Project website
4. README
5. Releases