Conta bancária fake para testes: Bradesco, Itaú e Nubank
Conta bancária fake para testes: Bradesco, Itaú e Nubank
Testar um fluxo de pagamento sem conta bancária válida em formato significa errar no DV e perder horas depurando uma validação que não deveria existir. Este artigo mostra como gerar contas bancárias fictícias com agência, número e dígito verificador corretos para Bradesco, Itaú, Nubank e mais 14 bancos, usando a API FakeForge ou a interface web.
O que é uma conta bancária fake e quando você precisa de uma
Diferença entre dado fake e dado falso
Dado fake é gerado sinteticamente para ter o formato correto, sem corresponder a nenhum titular real. Dado falso é um dado real adulterado ou usado fora do contexto original. A distinção importa porque dado falso pode ter origem ilícita. Dado fake, quando gerado por ferramenta que não usa base de pessoas reais, não coloca ninguém em risco e não viola a LGPD.
Casos de uso legítimos
Os mais comuns no dia a dia:
- Fixtures em testes de integração que validam o dígito verificador antes de persistir.
- Seeds de banco de dados para ambiente de desenvolvimento e staging.
- Demos de produto sem exposição de dados reais de clientes.
- Pipelines de CI/CD que precisam de dados bancários no schema sem depender de produção.
- Payloads de exemplo em documentação de API interna.
O que a conta precisa ter para ser útil
Número de conta gerado aleatoriamente sem DV válido falha na primeira chamada ao backend. Para ser útil em testes, a conta precisa ter: código COMPE do banco, número de agência no formato do banco, número de conta no formato do banco, dígito verificador correto pelo algoritmo do banco. Sem isso, o teste valida o caminho feliz de uma entrada que nunca ocorreria em produção.
Estrutura de uma conta bancária brasileira
Composição: COMPE, agência, conta, dígito verificador
O COMPE (Catálogo de Identificadores de Participantes do SPB) é o código de três dígitos que identifica o banco. A agência tem quatro dígitos em quase todos os bancos, podendo ter um DV próprio. A conta tem entre cinco e oito dígitos dependendo do banco, seguida de um DV. O Banco Central publica a lista COMPE atualizada em bcb.gov.br.
Como o dígito verificador é calculado
A maioria dos bancos usa módulo 11, mas com variações no conjunto de pesos, no tratamento de resultado 0, 1 ou igual ao módulo. Itaú usa pesos 2 a 9 aplicados da direita para esquerda, soma reduzida módulo 10. Bradesco usa módulo 11 com DV separado para agência e conta. Nubank delega para a estrutura Pagar.me e usa agência fixa 0001 sem DV de agência. Não existe um algoritmo único para todos os bancos brasileiros.
Por que gerar sem validar o DV quebra testes
Um campo de formulário ou endpoint que recebe dados bancários geralmente valida o DV antes de gravar. Se o dado fake não passa nessa validação, o teste falha por motivo errado. O erro aponta para o payload do teste, não para a lógica que você quer exercitar. Gerar dados com DV correto elimina esse ruído.
Principais bancos e seus formatos de conta
| Banco | Código COMPE | Agência | DV Agência | Conta | DV Conta |
|---|---|---|---|---|---|
| Banco do Brasil | 001 | 4 dígitos | 1 dígito | 8 dígitos | 1 dígito |
| Bradesco | 237 | 4 dígitos | 1 dígito | 7 dígitos | 1 dígito |
| Itaú | 341 | 4 dígitos | sem DV | 5 dígitos | 1 dígito |
| Caixa Econômica | 104 | 4 dígitos | 1 dígito | 11 dígitos | 1 dígito |
| Santander | 033 | 4 dígitos | 1 dígito | 8 dígitos | 1 dígito |
| Nubank | 260 | 0001 (fixo) | sem DV | 7 dígitos | 1 dígito |
| Inter | 077 | 4 dígitos | sem DV | 7 dígitos | 1 dígito |
| C6 Bank | 336 | 0001 (fixo) | sem DV | 7 dígitos | 1 dígito |
Bradesco (banco 237)
Agência com quatro dígitos numéricos mais um DV calculado por módulo 7. Conta com sete dígitos mais um DV calculado por módulo 11. Valores 0 e 1 como resto do módulo 11 resultam em DV "0" na maioria das implementações. Bradesco é o banco com maior variação em sistemas legados, por isso o formato exato depende do sistema de destino.
Itaú (banco 341)
Agência com quatro dígitos sem DV. Conta com cinco dígitos mais um DV calculado por módulo 10 com pesos alternados 2 e 1. É o formato mais simples entre os grandes bancos.
Nubank (banco 260)
Conta corrente digital com agência fixa 0001. Não há DV de agência. O DV de conta usa módulo 11 com pesos 2 a 9. Por ter agência fixa, é o banco mais fácil de gerar manualmente, mas o DV de conta ainda precisa ser calculado corretamente.
Outros bancos cobertos
Caixa Econômica (104) tem o formato mais longo, com 11 dígitos de conta. Banco do Brasil (001) tem 8 dígitos de conta. Inter (077) e C6 (336) seguem estrutura digital com agências reduzidas. O gerador de conta bancária cobre todos esses formatos com DV válido.
Gerando contas bancárias fake com a API FakeForge
Endpoint e parâmetros
curl "https://fakeforge.com.br/api/generate?type=conta-bancaria&quantity=5&format=json"Substitua format=json por format=csv ou format=sql para outros formatos. O parâmetro quantity aceita até 10.000 itens por chamada. Para gerar apenas contas Nubank, adicione bank=260 (campo em roadmap, verificar disponibilidade em /docs).
Resposta JSON
interface BankAccount {
bank: string; // "Nubank"
bankCode: string; // "260"
agency: string; // "0001"
agencyDigit: string; // "" (quando sem DV)
account: string; // "1234567"
accountDigit: string;// "9"
type: "corrente" | "poupanca";
}
interface GenerateResponse {
_meta: {
source: string;
url: string;
generated_at: string;
license: string;
};
type: string;
quantity: number;
data: BankAccount[];
}Export CSV para seed scripts
curl "https://fakeforge.com.br/api/generate?type=conta-bancaria&quantity=100&format=csv" \
-o contas_teste.csvO arquivo inclui cabeçalho com os nomes das colunas. Importa diretamente em scripts de seed com COPY no PostgreSQL ou LOAD DATA INFILE no MySQL.
Export SQL com CREATE TABLE
-- Generated by FakeForge BR -- free Brazilian test data
-- https://fakeforge.com.br
-- Generated at: 2026-05-26T14:23:51Z
-- License: CC0 (public domain test data)
CREATE TABLE IF NOT EXISTS bank_accounts (
id SERIAL PRIMARY KEY,
bank VARCHAR(100) NOT NULL,
bank_code CHAR(3) NOT NULL,
agency VARCHAR(4) NOT NULL,
agency_digit VARCHAR(1),
account VARCHAR(11) NOT NULL,
account_digit CHAR(1) NOT NULL,
type VARCHAR(10) NOT NULL
);
INSERT INTO bank_accounts (bank, bank_code, agency, agency_digit, account, account_digit, type)
VALUES
('Bradesco', '237', '3142', '5', '9876543', '2', 'corrente'),
('Nubank', '260', '0001', '', '4521876', '3', 'corrente'),
('Itaú', '341', '7823', '', '45123', '7', 'poupanca');O export SQL do FakeForge gera CREATE TABLE compatível com PostgreSQL e MySQL. Use format=sql no endpoint.
Gerando contas via web sem escrever código
Selecionando banco específico vs. banco aleatório
Na interface do gerador de conta bancária, o seletor de tipo permite escolher um banco específico ou manter a opção aleatória. Para demonstrações, escolher um banco específico evita confusão com o cliente que reconhece apenas o logo do banco habitual dele.
Copiando item por item ou exportando lote
Cada resultado tem botão de cópia individual. Para lotes maiores, os botões de export no topo geram o arquivo no formato selecionado. O lote máximo pela interface web é 50 itens. Para volumes maiores, use a API.
Usando como fixture em Postman ou Insomnia
Gere 10 contas em JSON, copie o array data e cole como body de uma collection do Postman. Ou use a URL do endpoint diretamente em um pré-script de request para gerar dados frescos a cada execução.
Gerando contas bancárias fake em TypeScript
Fetch com tipagem
import type { BankAccount, GenerateResponse } from "./types/fakeforge";
async function fetchFakeBankAccounts(quantity = 10): Promise<BankAccount[]> {
const url = new URL("https://fakeforge.com.br/api/generate");
url.searchParams.set("type", "conta-bancaria");
url.searchParams.set("quantity", String(quantity));
url.searchParams.set("format", "json");
const res = await fetch(url.toString());
if (!res.ok) throw new Error(`FakeForge HTTP ${res.status}`);
const body: GenerateResponse = await res.json();
return body.data;
}Setup de fixture em Jest
import { fetchFakeBankAccounts } from "../helpers/fakeforge";
import type { BankAccount } from "../types/fakeforge";
describe("BankAccountService", () => {
let accounts: BankAccount[];
beforeAll(async () => {
accounts = await fetchFakeBankAccounts(20);
});
it("aceita conta Nubank com agência 0001", () => {
const nubank = accounts.find((a) => a.bankCode === "260");
expect(nubank).toBeDefined();
expect(nubank?.agency).toBe("0001");
});
it("rejeita conta com DV inválido", () => {
const invalid = { ...accounts[0], accountDigit: "X" };
expect(() => BankAccountService.validate(invalid)).toThrow();
});
});DICA: ChamefetchFakeBankAccountsembeforeAll, não embeforeEach. Uma chamada por suite economiza o limite de 100 chamadas/dia do plano gratuito.
Gerando contas bancárias fake em Python
Chamada com httpx e conversão para DataFrame
import httpx
import pandas as pd
def fetch_bank_accounts(quantity: int = 50) -> pd.DataFrame:
url = "https://fakeforge.com.br/api/generate"
params = {"type": "conta-bancaria", "quantity": quantity, "format": "json"}
with httpx.Client(timeout=10) as client:
res = client.get(url, params=params)
res.raise_for_status()
data = res.json()["data"]
return pd.DataFrame(data)
df = fetch_bank_accounts(100)
print(df.head())Salvando CSV com encoding UTF-8-BOM para Excel
df.to_csv(
"contas_fake.csv",
index=False,
encoding="utf-8-sig", # BOM garante leitura correta no Excel PT-BR
)O encoding utf-8-sig (UTF-8 com BOM) evita que o Excel interprete acentos como caracteres corrompidos em Windows. Pandas e outros consumidores Python ignoram o BOM sem problemas.
Boas práticas LGPD ao usar dados fictícios em testes
Por que dados reais violam a LGPD Art. 7º, IX
A LGPD Art. 7º, IX exige base legal para todo tratamento de dados pessoais. Testes de software não se enquadram em nenhuma das bases legais listadas quando o ambiente de teste não tem as mesmas salvaguardas do ambiente de produção. Usar conta bancária real de um cliente em um banco de dados de desenvolvimento que o estagiário acessa é tratamento sem base legal.
Segregação de ambientes como controle técnico
A LGPD Art. 46 exige medidas técnicas e administrativas para proteger dados pessoais. Segregar ambientes e usar dados fictícios em dev e staging é um controle técnico documentável. Quando a ANPD analisa um incidente, a ausência desse controle agrava a avaliação.
Como documentar o uso
Na política de privacidade ou no registro de operações de tratamento, inclua: "Ambientes de desenvolvimento e teste utilizam exclusivamente dados fictícios gerados sinteticamente. Nenhum dado pessoal de titulares é replicado fora do ambiente de produção." Essa linha fecha a lacuna quando um auditor pergunta o que acontece com dados de clientes fora de produção.
Comparando abordagens
Implementação manual
Implementar o cálculo de DV manualmente é a fonte mais comum de bugs silenciosos. O módulo 11 com tratamento de resto 0 e 1 varia por banco. Bradesco e Itaú têm regras diferentes para o mesmo algoritmo base. A maioria das implementações encontradas em Stack Overflow e GitHub Gist tem pelo menos um caso de borda errado.
Faker.js e Faker (Python)
Faker.js gera números de conta no formato norte-americano (routing number + account number). Não há suporte a COMPE, agência brasileira ou DV calculado por algoritmo bancário nacional. Faker em Python tem situação equivalente. Ambas as bibliotecas são ótimas para dados genéricos, mas não cobrem o formato bancário brasileiro com DV válido. A comparação detalhada está em /comparacao/fakeforge-vs-alternativas.
FakeForge
Uma chamada à API retorna banco, código COMPE, agência, DV de agência, conta e DV de conta em um único objeto consistente. Os campos são correlacionados: o bankCode corresponde ao bank, o DV foi calculado pelo algoritmo correto para aquele banco. Não há pós-processamento necessário para usar nos testes.
Limites e o que a conta fake não substitui
Não é uma conta real
Uma conta fake não tem titularidade no SPB. Não funciona para TED, PIX ou qualquer operação que o Banco Central processa contra a base de contas cadastradas. Usar uma conta fake em uma transação real resulta em rejeição imediata pela instituição financeira recebedora.
AVISO: Nunca use dados fictícios em campos de formulários de instituições financeiras reais, mesmo para "testar" um endpoint de produção. Isso pode ser interpretado como tentativa de fraude independente da intenção.
Quando usar sandbox oficial
Para testes de integração que chegam até a API do banco (open banking, PIX real, TED), use o sandbox oficial. Bradesco tem o Bradesco Sandbox em developers.bradesco.com.br. Itaú tem o Itaú Developer Portal em developer.itau.com.br. O BACEN mantém o PIX Homologação para instituições participantes. Esses ambientes exigem credencial e aprovação do banco, mas são necessários quando o teste precisa de uma resposta real da infraestrutura bancária.
Quando a conta fake é suficiente
Conta fake cobre todo cenário onde o sistema sendo testado valida o formato e o DV sem chamar nenhuma API externa. Formulários de cadastro, validações de backend, seeds de banco de dados, fixtures de testes unitários e de integração que mocam a chamada ao banco: esses cenários não precisam de sandbox. Conta fake é a escolha correta para 90% dos casos de teste que envolvem dados bancários.
Resumo
- Use dados fictícios de conta bancária em todos os ambientes fora de produção para cumprir LGPD Art. 7º, IX sem precisar anonimizar base real.
- Confira o código COMPE e o algoritmo de DV antes de implementar manualmente: cada banco tem variação no módulo 11.
- Para seeds em TypeScript, chame a API em
beforeAlle reutilize o lote na suite inteira para não consumir o limite de 100 chamadas/dia do plano gratuito. - Para pipelines de dados em Python, use
utf-8-sigao salvar CSV para evitar problema de encoding no Excel PT-BR. - Quando o teste precisa de resposta real da infraestrutura bancária, use o sandbox oficial do banco, não conta fake.
- Para o mesmo titular fictício, combine conta bancária com CPF fake, chave PIX e dados completos de pessoa em uma única chamada à API usando múltiplos tipos. O plano Dev (R$29/mês) remove o limite de 100 chamadas/dia se o volume de testes exigir.
Perguntas frequentes
Como sei se meu backend está realmente validando o DV ou apenas aceitando qualquer coisa?+
Teste com DV inválido propositalmente para validar que backend rejeita. Gere com FakeForge (DV correto, deve passar) e manualmente com DV errado (deve falhar). Se ambos passam, backend não valida DV — bug. Exemplo: expect(validate(conta)).toBe(true) vs expect(validate(invalidConta)).toBe(false).
Posso reutilizar a mesma conta fake em múltiplos testes ou devo gerar uma nova cada vez?+
Reutilize para economizar chamadas à API. Contas fake são dados estáticos sem 'sessão'—o mesmo objeto pode ser usado em 100 testes. Coloque em beforeAll, exporte e importe em todos os testes da suite. Evita consumir limite de 100 chamadas/dia do free tier.
É mais eficiente gerar 100 contas em uma chamada ou fazer 100 chamadas de 1 conta cada?+
Uma chamada com quantity=100 é mais eficiente: economiza 99 requisições HTTP e roda rápido. Gere uma vez em beforeAll, copie o array na fixture, itere nos testes sem chamar API novamente. Alternativa: salve em .json local versionado para rodar CI/CD offline sem consumir limite diário.
Como faço testes de integração com PIX real ou TED se conta fake não funciona no Banco Central?+
Use sandbox oficial: Bradesco (developers.bradesco.com.br), Itaú (developer.itau.com.br), BACEN PIX Homologação. Requerem credencial mas validam contra banco real. Conta fake é para formato/DV local, sandbox é para fluxo de dinheiro. Escolha conforme teste exigir resposta real.
Posso combinar conta bancária fake com CPF fake e pessoa fake para um titular fictício completo?+
Sim, é possível. Gere cada tipo separado com quantity=1 e combine os dados: { cpf, conta, pessoa, chave_pix }. Ou use gerador multi-tipo em uma chamada (roadmap futuro). Crie factory que monta titular fictício completo: createFakePerson() => ({ cpf, conta, ...pessoa }). Reutilize em testes de onboarding.