Gerador de Conta Bancária: 17 Bancos BR para Testes

Cada banco brasileiro define sua própria máscara de conta. Itaú tem quatro algarismos de agência sem dígito; Bradesco tem quatro com dígito; CEF usa seis para conta-poupança com prefixo 013. Quando um pipeline de testes precisa cobrir transferências TED, TEF, PIX e boleto ao mesmo tempo, hardcodar um único número de conta quebra casos de borda que só aparecem em produção. Esta referência cobre os 17 bancos incluídos no gerador de conta bancária do FakeForge BR, explica os esquemas de numeração, e mostra como integrar dados fictícios válidos em CI/CD sem violar a LGPD.

Formato de conta bancária no Brasil não é uniforme

O papel do código COMPE e do código ISPB

O COMPE (Centralizador da Compensação de Cheques) é o código de três dígitos usado em TED e DOC. O ISPB (Identificador de Sistema de Pagamentos Brasileiro) é o código de oito dígitos do SPB, obrigatório em mensagens ISO 20022 e em transferências via PIX. Nubank, por exemplo, aparece como 260 no COMPE e 18236120 no ISPB. Testes que validam formulários de TED precisam do COMPE; testes de integração com o SPI precisam do ISPB. Gerar o código errado para o contexto errado é a causa mais comum de falhas silenciosas em ambientes de staging.

Agência com e sem dígito verificador: quem usa o quê

BB (001), Bradesco (237) e Santander (033) incluem dígito verificador na agência. Itaú (341) e CEF (104) não. Isso afeta diretamente a máscara de input e a lógica de validação de formulários. Formulários que exibem um campo único de agência sem separar o DV falham ao receber dados do Bradesco e passam silenciosamente com dados do Itaú — o comportamento contrário do esperado.

Conta corrente, poupança e conta de pagamento: diferenças de máscara

Conta corrente no BB tem cinco algarismos mais um DV. Conta-poupança na CEF adiciona o prefixo 013 antes dos onze dígitos, totalizando treze. Contas de pagamento em fintechs como Nubank e PagBank seguem o padrão interno da própria instituição, sem prefixo regulatório obrigatório — mas precisam estar dentro do comprimento máximo aceito pelo SPI (até 20 caracteres alfanuméricos).

Por que testes com dados reais são proibidos pela LGPD

LGPD Art. 7º, IX permite o tratamento de dados pessoais somente quando há legítimo interesse, e Art. 46 exige medidas técnicas adequadas para proteger dados em todas as fases do ciclo de vida — incluindo ambientes de teste. Usar números de conta reais capturados de clientes em seeds de banco de dados de staging é uma violação direta desses artigos. Dados fictícios gerados por ferramenta adequada eliminam o risco porque não há titular identificável.

AVISO: Substituir dados reais por dados fictícios em pipelines de CI/CD não é otimização — é requisito legal. A ANPD já emitiu guias sobre pseudonimização em ambiente de desenvolvimento. Dados fictícios estruturalmente válidos são a abordagem mais segura.

Os 17 bancos cobertos e seus esquemas de numeração

Bancões tradicionais (BB 001, Bradesco 237, Itaú 341, CEF 104, Santander 033)

Os cinco maiores bancos do país definem o comportamento esperado pela maioria dos sistemas legados. BB usa agência de quatro dígitos sem DV e conta de oito com DV mod-11. Bradesco usa agência de quatro com DV e conta de sete com DV. Itaú usa agência de quatro sem DV e conta de cinco mais DV. CEF usa agência de quatro sem DV e conta de onze mais DV (ou treze para poupança). Santander usa agência de quatro sem DV e conta de oito com DV mod-11.

Bancos digitais de primeira geração (Nubank 260, Inter 077, C6 336)

Nubank, Inter e C6 Bank abriram conta digital em larga escala e trouxeram formatos menos documentados publicamente. Nubank usa contas de sete dígitos sem separação de agência explícita no produto, mas expõe 0001 como agência padrão para TEDs. Inter e C6 seguem lógica similar. Testes de onboarding que validam transferências para contas digitais precisam cobrir o padrão 0001 de agência.

Bancos de nicho e corretoras (BTG 208, XP, Sicoob 756, Sicredi 748)

Cooperativas de crédito como Sicoob e Sicredi têm centenas de cooperativas singulares, cada uma com seu próprio código de agência interno. Para testes, o gerador usa agências válidas dentro do range documentado pelo próprio sistema de cada cooperativa. BTG e XP têm contas de investimento que coexistem com contas de pagamento no mesmo número de cliente — o campo tipo do payload distingue os casos.

Fintechs de pagamento (PagBank, Neon, Original 212, Mercado Pago, BV 413)

PagBank (COMPE 290), Neon (COMPE 735), Original (COMPE 212), Mercado Pago (COMPE 323) e BV (COMPE 413) são cobertas com formatos de conta validados contra a documentação SPI disponível no BACEN. Mercado Pago exige atenção especial: aceita CPF ou CNPJ como identificador alternativo em transferências, o que afeta testes de validação de onboarding.

Tabela consolidada: COMPE, dígito de agência, comprimento de conta, poupança

*XP opera contas de custódia na infraestrutura Itaú (COMPE 341) para transferências externas.

Estrutura interna de um número de conta válido para testes

Dígito verificador de conta: mod-10 vs mod-11 por banco

Banco do Brasil, CEF e Santander usam mod-11 com pesos variando por banco. Bradesco usa mod-11 com pesos 2,7,6,5,4,3,2 da esquerda para direita. Itaú usa mod-10. Gerar um DV errado faz o número passar na regex de máscara mas falhar em qualquer validação real — o pior tipo de falha de teste: silenciosa em CI, visível em produção.

Prefixo de poupança 013 na CEF e variações em outros bancos

Na CEF, conta-poupança começa com 013 seguido de onze dígitos. Conta corrente usa os mesmos onze dígitos sem prefixo. BB usa o dígito 51 como prefixo de poupança dentro do número da conta — não como campo separado. O gerador FakeForge BR expõe o campo subtipo (corrente, poupanca, pagamento) no payload e já inclui o prefixo correto no campo conta.

Campos obrigatórios vs opcionais em formulários de transferência

Para TED: banco, agência, conta, tipo de conta e CPF/CNPJ do titular são obrigatórios. Para PIX: apenas a chave. Para boleto: linha digitável gerada pelo banco emissor — fora do escopo deste gerador. Testes de formulário precisam cobrir os campos opcionais com valores nulos e com valores inválidos separadamente.

Como gerar contas bancárias fictícias com a API FakeForge BR

Endpoint básico via GET e resposta JSON com _meta

interface BankAccount {
  banco: string;
  compe: string;
  agencia: string;
  agenciaDv: string | null;
  conta: string;
  contaDv: string;
  subtipo: 'corrente' | 'poupanca' | 'pagamento';
  titular: string;
  cpf: string;
}

interface FakeForgeResponse {
  _meta: {
    source: string;
    url: string;
    generated_at: string;
    license: string;
  };
  type: string;
  quantity: number;
  data: BankAccount[];
}

const res = await fetch(
  'https://fakeforge.com.br/api/generate?type=conta-bancaria&quantity=5&format=json'
);
const payload: FakeForgeResponse = await res.json();
console.log(payload._meta.source); // "FakeForge BR"
console.log(payload.data[0].compe); // ex: "237"

Consulte a documentação completa da API REST para todos os parâmetros aceitos, incluindo bank e subtipo.

Selecionando banco específico no payload de request

Passe bank=237 na query string para restringir a geração ao Bradesco. O parâmetro aceita qualquer COMPE da tabela acima. Sem o parâmetro, o gerador distribui aleatoriamente entre os 17 bancos.

Exportando em CSV e SQL com CREATE TABLE pronto para seed

curl "https://fakeforge.com.br/api/generate?type=conta-bancaria&quantity=100&format=sql" \
  | psql "$DATABASE_URL" -f -

O SQL exportado inclui CREATE TABLE IF NOT EXISTS com os tipos corretos e INSERT INTO em lote. Ideal para scripts de seed em migrations Flyway ou Liquibase. O cabeçalho SQL traz comentário de atribuição que sobrevive à execução no psql, MySQL Workbench e DBeaver sem erro de sintaxe.

Rate limits: 100 chamadas/dia no plano gratuito, comportamento esperado

O plano gratuito retorna HTTP 429 após 100 chamadas diárias. O header X-RateLimit-Remaining informa o saldo antes de atingir o limite. Pipelines que rodam mais de 100 vezes por dia precisam do plano Dev (R$29) ou Team (R$79). Em CI, armazenar o fixture gerado como artefato evita chamadas redundantes entre reruns do mesmo job.

Integração em pipelines de CI/CD

Fixture estático no repositório vs geração dinâmica em runtime

Fixture estático (arquivo JSON commitado) é previsível e não depende de rede. Geração dinâmica garante variedade e cobre casos de borda que um fixture fixo nunca exercita. A recomendação: fixture estático para testes unitários de validação de máscara; geração dinâmica para testes de integração de end-to-end.

Usando a SDK TypeScript para gerar antes de cada suite de testes

import { beforeAll, afterAll, describe, it, expect } from '@jest/globals';

let contas: BankAccount[] = [];

beforeAll(async () => {
  const res = await fetch(
    'https://fakeforge.com.br/api/generate?type=conta-bancaria&quantity=20&format=json'
  );
  const payload: FakeForgeResponse = await res.json();
  contas = payload.data;
});

afterAll(() => {
  contas = [];
});

describe('Validação de formulário de TED', () => {
  it('rejeita agência com comprimento incorreto', () => {
    const conta = contas[0];
    expect(conta.agencia.length).toBeGreaterThanOrEqual(4);
  });
});

Parametrizando banco, tipo de conta e quantidade em variáveis de ambiente

const bank = process.env.TEST_BANK ?? '';
const subtipo = process.env.TEST_SUBTIPO ?? 'corrente';
const qty = Number(process.env.TEST_QTY ?? 10);

const url = new URL('https://fakeforge.com.br/api/generate');
url.searchParams.set('type', 'conta-bancaria');
url.searchParams.set('quantity', String(qty));
if (bank) url.searchParams.set('bank', bank);
url.searchParams.set('subtipo', subtipo);

Exemplo com Jest + Supertest contra ambiente de staging

No jest.config.ts, defina globalSetup apontando para o script de geração. O script grava o fixture em tmp/contas.json. Cada teste lê do arquivo, sem chamadas de rede no meio da suite.

Combinando conta bancária com outros geradores correlacionados

CPF do titular gerado junto (correlação pessoa + conta)

interface TestCustomer {
  nome: string;
  cpf: string;
  conta: BankAccount;
  pixKey: string;
}

async function buildTestCustomer(): Promise<TestCustomer> {
  const [pessoaRes, contaRes] = await Promise.all([
    fetch('https://fakeforge.com.br/api/generate?type=pessoa&quantity=1'),
    fetch('https://fakeforge.com.br/api/generate?type=conta-bancaria&quantity=1'),
  ]);

  const pessoa = (await pessoaRes.json()).data[0];
  const conta = (await contaRes.json()).data[0];

  return {
    nome: pessoa.nomeCompleto,
    cpf: pessoa.cpf,
    conta,
    pixKey: pessoa.cpf, // chave PIX tipo CPF
  };
}

Use /gerador-pessoa para nome, CPF e DDD coerentes com a região. Use /gerador-pix para chave PIX correlacionada ao mesmo titular.

Chave PIX derivada do CPF ou CNPJ para testes de transferência

Testes de fluxo de transferência precisam de par origem-destino consistente. Gerar CPF via /validar-cpf e derivar a chave PIX tipo CPF do mesmo número evita rejeição por inconsistência de titular no ambiente de staging.

CNPJ + conta corrente PJ para testes de onboarding empresarial

const [cnpjRes, contaPJRes] = await Promise.all([
  fetch('https://fakeforge.com.br/api/generate?type=cnpj&quantity=1'),
  fetch('https://fakeforge.com.br/api/generate?type=conta-bancaria&quantity=1&subtipo=corrente'),
]);

/gerador-cnpj gera CNPJ com dígitos verificadores válidos. Combine com conta corrente PJ para testes de abertura de conta empresarial. O campo titular do payload de conta aceita razão social quando o contexto é PJ.

Validação de dados bancários em aplicações de produção

Checagem de dígito verificador antes de persistir no banco de dados

Valide o DV no servidor antes de qualquer escrita. Um número de conta com DV inválido que passa pela API interna e chega ao legado bancário gera rejeição assíncrona horas depois — difícil de rastrear. A validação síncrona no serviço de recebimento corta esse ciclo.

Integração com a API do BACEN para validação de agência real

O BACEN disponibiliza o endpoint de consulta de participantes do SPI em https://www.bcb.gov.br/api/pix/v1/participantes. Em produção, valide que o COMPE informado pelo usuário existe nessa lista antes de tentar uma transferência. Em testes, não use esse endpoint — use dados fictícios que já passam na validação de formato.

O que validar em testes vs o que deixar para o ambiente real

Em testes: formato, comprimento, DV calculado, banco na lista autorizada. No ambiente real: existência da agência no cadastro BACEN, titularidade confirmada pelo banco destino, status da conta (ativa, encerrada, bloqueada). Misturar os dois contextos no mesmo teste cria dependências externas frágeis.

Conformidade com LGPD ao usar geradores de dados

LGPD Art. 7º, IX e o princípio da minimização de dados

LGPD Art. 7º, IX autoriza tratamento de dados pessoais para legítimo interesse, mas exige que o tratamento seja o mínimo necessário para a finalidade (Art. 6º, III — princípio da necessidade). Usar uma conta bancária real de um cliente para testar um fluxo de validação de DV não é necessário — um dado fictício estruturalmente válido serve ao mesmo propósito com risco zero.

Por que dados fictícios eliminam o risco de titular identificável

Dados gerados pelo FakeForge BR não correspondem a nenhum titular real. A geração é procedural: CPF, nome e conta são gerados de forma independente e nunca cruzados com bases reais. Não há como reverter o dado gerado a um titular, o que satisfaz o critério de pseudonimização descrito no Art. 13 da LGPD.

Cláusulas contratuais com fornecedores de dados de teste

Se sua empresa usa fornecedor externo de dados de teste que entrega dados reais anonimizados, exija no contrato: cláusula de limitação de finalidade (Art. 6º, I), responsabilidade solidária em caso de vazamento (Art. 42), e auditoria anual do processo de anonimização. Dados fictícios gerados localmente eliminam esse risco contratual completamente.

Comparativo: FakeForge BR vs alternativas para dados bancários

4devs.com.br: cobertura de bancos e ausência de API

4devs gera número de conta para alguns bancos via interface web, sem DV calculado por banco e sem API REST. Não há como integrar em pipeline automatizado. Útil para testes manuais pontuais; inadequado para CI/CD ou geração em volume.

Faker.js finance module: locale pt-BR incompleto, sem dígito verificador

O módulo finance do Faker.js gera IBANs, números de conta e BICs genéricos. O locale pt_BR não implementa lógica de DV por banco, não conhece o COMPE brasileiro e não produz formatos compatíveis com o SPI. Qualquer dado gerado falha na primeira validação de formato real.

Dados manuais hardcoded: custo de manutenção ao longo do tempo

Um arquivo fixtures/contas.json com dez contas escritas à mão parece suficiente no dia zero. Seis meses depois, o time descobriu que nenhuma cobre conta-poupança CEF, nenhuma tem DV calculado para Santander, e três números são idênticos porque foram copiados de um tutorial. O custo de manutenção de fixtures manuais cresce com a cobertura de testes.

Tabela de decisão: quando cada abordagem faz sentido

DICA: Para equipes que ainda usam hardcode, o caminho mais rápido é substituir o arquivo de fixture pelo output SQL da API — um curl no script de seed e o fixture deixa de ser mantido manualmente. Veja o comparativo completo contra Faker.js e 4devs para dados de cobertura.

Resumo

• Os 17 bancos têm esquemas de agência e conta diferentes; gerar dados genéricos sem DV calculado por banco produz falhas silenciosas em validadores reais.
• Dados fictícios estruturalmente válidos são o único caminho compatível com LGPD Art. 7º, IX e Art. 46 para pipelines de teste.
• A API FakeForge BR aceita bank, subtipo e format como parâmetros; o export SQL inclui CREATE TABLE pronto para seed.
• Combine conta bancária com CPF e PIX para cobrir fluxos de transferência de ponta a ponta sem depender de dados reais.
• Plano gratuito cobre 100 chamadas/dia; para CI/CD com múltiplos jobs, armazene o fixture gerado como artefato entre reruns ou migre para o plano Dev ou Team.
• O próximo passo concreto é substituir o fixture hardcoded mais antigo do repositório pelo output SQL da API — um curl no script de seed resolve sem alterar a lógica de nenhum teste.