Segurança de plataforma para cartões pré-pagos white label

Última atualização: 18 de julho de 2026

Principais lições deste artigo

• Plataformas de emissão de cartões pré-pagos white label via Banking as a Service precisam atender simultaneamente a PCI DSS 4.0, regras do Banco Central e LGPD, mantendo velocidade de lançamento.

• Falhas de segurança na infraestrutura impactam diretamente a marca do cliente final e podem gerar multas de até R$ 50 milhões ou descredenciamento de BIN.

• Ter uma arquitetura segura exige quatro camadas, perímetro, aplicação, dados e rede, com MFA obrigatório, criptografia AES-256, tokenização end-to-end e isolamento multi-tenant por schema ou banco.

• Em 2026, provedores precisam entregar relatórios regulatórios automatizados, KYC e AML integrados e conformidade contínua com PCI DSS 4.0 e Open Finance.

• Para implementar uma solução completa e segura de cartões white label, vale conhecer a Celcoin.

Por que a segurança da plataforma é crítica na emissão de cartões pré-pagos white label?

A segurança da plataforma define o risco regulatório e de imagem na emissão de cartões pré-pagos white label. No modelo Banking as a Service, a empresa que lança o cartão opera sob a infraestrutura regulatória do provedor, o que acelera o lançamento, mas também compartilha o impacto de qualquer falha de segurança.

Os riscos concretos de uma plataforma mal estruturada incluem:

• Vazamento de dados de portadores de cartão, com penalidades de até R$ 50 milhões por infração sob a LGPD.

• Descredenciamento de BIN pela bandeira por não conformidade com PCI DSS.

• Multas e intervenções do Banco Central por falhas em controles de prevenção à lavagem de dinheiro e KYC.

• Fraudes não detectadas que corroem a margem operacional.

Construir essa infraestrutura do zero exige anos de desenvolvimento, equipes especializadas e investimentos em certificações. Escolher um provedor que já entregue esses requisitos de forma nativa reduz tempo, custo e exposição a riscos.

Conceitos essenciais

Alinhar alguns conceitos facilita a avaliação de arquitetura e de requisitos regulatórios.

• Cartão pré-pago white label: cartão emitido com a marca de uma empresa não financeira, como varejista, ERP ou fintech, operado sobre a infraestrutura e as licenças de um provedor de Banking as a Service.

• Banking as a Service: modelo em que um provedor licenciado disponibiliza APIs modulares para que terceiros ofereçam serviços financeiros sem licença própria.

• BIN compartilhado: número de identificação bancária compartilhado entre múltiplos emissores, o que reduz custos de volumetria e acelera o acesso à bandeira.

• PCI DSS 4.0: padrão internacional de segurança para dados de cartão, com 64 requisitos novos ou revisados, dos quais mais de 50 tornaram-se obrigatórios em março de 2025.

• Tokenização: substituição do número real do cartão por um identificador sem valor fora do sistema emissor, o que remove o dado sensível do fluxo transacional.

• Isolamento multi-tenant: separação lógica ou física dos dados de cada cliente dentro de uma plataforma compartilhada, impedindo acesso cruzado entre organizações.

Arquitetura segura de uma plataforma de cartões

Uma plataforma de emissão de cartões pré-pagos white label segura se organiza em quatro camadas sobrepostas.

1. Camada de perímetro: uso de firewall de aplicação web, proteção contra DDoS, rate limiting por tenant e filtragem de IP com detecção de VPNs, proxies e redes TOR.

2. Camada de aplicação: autenticação multifator obrigatória para todos os acessos ao ambiente de dados de portadores de cartão, requisito explícito do PCI DSS 4.0, controle de acesso baseado em função com escopo por tenant e senhas mínimas de 12 caracteres.

3. Camada de dados: criptografia AES-256 em repouso e TLS 1.2 ou superior em trânsito, chaves gerenciadas por HSM com rotação periódica e tokenização end-to-end do PAN desde a emissão até o processamento.

4. Camada de rede: segmentação por microsserviços, comunicação interna via mTLS e isolamento de workloads de alto risco em nós dedicados.

O ciclo de vida do cartão, emissão física e virtual, ativação, bloqueio temporário, desbloqueio e cancelamento definitivo, precisa ser gerenciado por APIs auditadas. Cada evento deve ser registrado em logs de auditoria com retenção alinhada ao PCI DSS 4.0.

Para o isolamento multi-tenant, plataformas que atendem a requisitos de conformidade financeira devem priorizar modelos de banco de dados por tenant ou schema por tenant. Em contextos com PCI DSS, LGPD e SOC 2 Type II, os modelos Database-per-Tenant ou Schema-per-Tenant são os mais indicados. Em ambos os casos, políticas de Row-Level Security no banco de dados garantem que uma consulta malformada na camada de aplicação não exponha dados de outro tenant.

Veja como a Celcoin implementa isolamento multi-tenant e tokenização nativa em sua plataforma.

Panorama regulatório brasileiro em 2026

O ambiente regulatório brasileiro em 2026 se mostra mais rigoroso para emissores de cartões pré-pagos.

• Banco Central: as resoluções para Instituições de Pagamento exigem controles de segurança cibernética documentados, planos de continuidade operacional, reportes regulatórios automatizados, como DIMP, CADOCs e CCS, e conexão direta à Rede do Sistema Financeiro Nacional.

• PCI DSS 4.0: desde março de 2025, os requisitos de MFA mencionados anteriormente tornaram-se obrigatórios, junto com revisão anual de suítes criptográficas e documentação de escopo a cada seis meses para provedores de serviço.

• LGPD: o artigo 46 exige medidas técnicas e organizacionais documentadas, como criptografia em repouso e em trânsito, controles de acesso, logs de auditoria e mapeamento de todos os processadores terceiros. O artigo 48 determina notificação à ANPD em caso de incidente de segurança relevante.

• Regras Visa: exigência de conformidade com programas de segurança da bandeira, gestão de disputas e chargeback e uso de tokenização para transações card-not-present.

• Open Finance: necessidade de transmitir e receber dados financeiros com consentimento do usuário, seguindo padrões técnicos e de segurança definidos pelo Banco Central.

Boas práticas e critérios de avaliação

Avaliar uma plataforma de emissão de cartões white label exige olhar para segurança, arquitetura, prevenção a fraudes e conformidade regulatória de forma integrada.

Comece pelos controles de segurança e conformidade que formam a base da operação.

1. Manter certificação PCI DSS 4.0 ativa, com QSA independente.

2. Implementar tokenização nativa end-to-end do PAN, sem armazenamento do número real fora do HSM.

3. Aplicar MFA obrigatório para todos os perfis de acesso ao ambiente de dados de cartão.

4. Garantir isolamento multi-tenant com segregação de dados por schema ou banco dedicado para tenants regulados.

5. Operar controles de fraude em tempo real com scoring por machine learning em baixa latência.

6. Configurar regras de velocidade por tenant, com janelas deslizantes dinâmicas.

7. Integrar KYC e AML ao onboarding, com monitoramento comportamental contínuo.

8. Realizar testes de penetração periódicos com escopo específico para acesso cross-tenant.

9. Registrar logs de auditoria com retenção alinhada às exigências regulatórias e campos de tenant_id estruturados.

10. Disponibilizar APIs para Pix REST bem documentadas, com sandbox, SDKs e suporte ao desenvolvedor.

11. Gerar relatórios regulatórios automatizados, como DIMP, CADOCs, CCS e COSIF, com envio direto ao Banco Central.

A tabela abaixo resume os critérios de avaliação por dimensão.

Dimensão	Critério mínimo	Critério avançado	Risco se ausente
Segurança de dados	Criptografia AES-256 em repouso e TLS 1.2 em trânsito	HSM dedicado com rotação de chaves a cada 90 dias	Violação de LGPD e PCI DSS
Isolamento multi-tenant	Row-Level Security com tenant_id em todas as tabelas	Schema ou banco dedicado por tenant regulado	Vazamento cross-tenant
Prevenção a fraudes	Velocity rules e bloqueio por IP	Scoring ML em tempo real com feedback loop de chargebacks	Perdas operacionais e descredenciamento
Conformidade regulatória	PCI DSS 4.0 certificado e LGPD documentada	Relatórios Bacen automatizados e DPO com autonomia operacional	Multas e intervenção regulatória

Erros comuns que comprometem a segurança

Alguns padrões de arquitetura e operação aumentam de forma relevante o risco de segurança e de não conformidade.

• Contas-bolsão: misturar recursos de múltiplos clientes em uma única conta não individualizada é irregular e vedado pelas normativas do Banco Central. A ausência de contas individualizadas impede rastreabilidade e viola obrigações de segregação patrimonial.

• Ausência de isolamento de tenant: aplicar o filtro de tenant_id apenas na camada de aplicação, e não no banco de dados, expõe todos os tenants a qualquer bug de código que omita o filtro.

• Tokenização ausente ou parcial: armazenar o PAN em texto claro em qualquer ponto do fluxo invalida a conformidade com PCI DSS e amplia de forma significativa a superfície de ataque.

• Subestimar PCI DSS e LGPD: tratar essas obrigações como checklist pontual, e não como processos contínuos, gera lacunas que costumam aparecer apenas em auditorias ou após incidentes.

• Stack fragmentado de fornecedores: integrar antifraude, KYC, processamento e relatórios regulatórios de fornecedores distintos aumenta superfícies de ataque, pontos de falha e complexidade de gestão de contratos.

Aplicações por tipo de empresa

Fintechs e bancos digitais usam cartões white label para monetizar a base de usuários com produtos de conta completa. A plataforma precisa suportar emissão de cartões físicos e virtuais, controle de limites em tempo real e integração com Pix e TED.

ERPs embarcam cartões pré-pagos para automatizar pagamentos a fornecedores, reembolsos de despesas e antecipação de recebíveis diretamente no fluxo de gestão dos seus clientes. A integração via API REST com documentação clara reduz o tempo de desenvolvimento.

Varejistas de grande porte lançam cartões com marca própria para criar programas de fidelidade, aumentar o ticket médio e capturar dados transacionais que alimentam estratégias de personalização. O compartilhamento de BIN reduz os custos de volumetria exigidos pela bandeira.

A Celcoin não oferece nenhum tipo de empréstimo para consumidores. A Celcoin fornece a infraestrutura tecnológica para que empresas consigam ofertar produtos de crédito aos seus clientes.

Celcoin: infraestrutura full-stack para cartões white label seguros

A Celcoin opera com portfólio completo de licenças e tecnologia proprietária, entregando APIs modulares para emissão de cartões pré-pagos e pós-pagos com marca própria. A solução inclui integração com a bandeira Visa, antifraude nativo, embossing, gestão de disputas, emissão de cartões físicos e virtuais e relatórios regulatórios automatizados, sob um único contrato. Empresas sem licença própria operam sob a licença de Instituição de Pagamento da Celcoin, enquanto empresas que já possuem licença integram-na ao Core Banking, mantendo a mesma base tecnológica e os mesmos controles de segurança.

Funcionalidade da Celcoin	Benefício para sua empresa
APIs modulares	Integrações mais rápidas, com redução de custos e prazos de desenvolvimento.
Experiência e suporte ao desenvolvedor	Documentação, SDKs e sandboxes que reduzem ciclos de integração e custos de engenharia.
Capacidade de lançamento rápido	Módulos pré-construídos e entrega via SaaS aceleram lançamentos, melhorando o tempo para geração de receita.
Distribuição white-label e embutida	Suporte a produtos financeiros com marca própria.
Escalabilidade com confiabilidade	Solução com alta disponibilidade e escalável na nuvem mantém serviços funcionando mesmo com altos volumes, protegendo a receita.
Cobertura de diversas possibilidades de pagamentos, incluindo crédito	Oferecer pagamentos e emissão de crédito aumenta conversão, ARPU e fidelização.
Acesso a dados e personalização	Dados e análises via Open Finance permitem ofertas personalizadas, com impacto em conversão e retenção.
Compliance e conformidade como princípio	KYC, AML e relatórios integrados reduzem risco regulatório e aceleram ciclos de vendas.
Prevenção de fraude e controles de risco	Monitoramento baseado em IA e autenticação robusta reduzem estornos, perdas e exposição regulatória.
Força do ecossistema de parceiros da Celcoin	Parcerias e integrações com bancos, redes e fintechs garantem cobertura ampla, mais recursos e velocidade de entrada no mercado.

Quer aprofundar como essas funcionalidades se conectam à estratégia da sua empresa? Explore todas as funcionalidades da plataforma Celcoin.

Perguntas frequentes

Tem dúvidas sobre como implementar cartões white label na sua empresa? Fale com nossos especialistas ou consulte as perguntas frequentes abaixo.

A tokenização é obrigatória para emissores de cartões pré-pagos white label no Brasil?

Sim. A tokenização é exigida pelo PCI DSS 4.0 e pelas regras operacionais da bandeira Visa para transações card-not-present. Na prática, o número real do cartão precisa ser substituído por um token desde o momento da emissão, de modo que nenhum sistema downstream, incluindo o da empresa que opera o cartão white label, armazene ou transmita o PAN em texto claro. Plataformas que não implementam tokenização nativa expõem o emissor a descredenciamento de BIN e a sanções regulatórias sob a LGPD.

É necessário ter BIN próprio para lançar um cartão white label?

Não. O modelo de BIN compartilhado permite que múltiplos emissores operem sob o mesmo BIN de um provedor habilitado junto à bandeira, o que reduz de forma relevante os requisitos de volumetria e os custos de entrada. Esse modelo atende especialmente fintechs em estágio inicial, ERPs e varejistas que ainda não atingiram os volumes mínimos exigidos para obter um BIN exclusivo. À medida que a operação cresce, a migração para BIN próprio pode ocorrer sem necessidade de trocar de plataforma.

Quanto tempo leva para implementar uma solução de cartão white label via Banking as a Service?

O prazo depende da complexidade da integração e da disponibilidade das equipes envolvidas. Em cenários mais simples, com APIs bem documentadas e equipe técnica dedicada, a implementação pode ser concluída em cerca de uma semana. Projetos com integrações mais elaboradas, como conexão com sistemas legados de ERP ou migração de base de cartões existente, podem levar até três meses. A qualidade da documentação e do suporte ao desenvolvedor oferecidos pelo provedor de Banking as a Service costuma ser o principal fator de aceleração.

Como funciona a migração de outra plataforma para um novo provedor de Banking as a Service de cartões?

A migração segue três etapas principais. A primeira etapa é o mapeamento dos dados existentes, como portadores, saldos e histórico transacional. A segunda etapa é a integração das APIs do novo provedor em ambiente de sandbox. A terceira etapa é a migração gradual da base de cartões, com período de operação paralela para validação.

O ponto crítico é garantir que os tokens de cartão sejam remapeados corretamente e que os controles de KYC e AML sejam revalidados para toda a base migrada, em linha com as exigências do Banco Central. Provedores com equipe de suporte técnico dedicada reduzem de forma significativa o risco operacional nessa fase.

Qual é o nível de suporte técnico esperado de um provedor de Banking as a Service para cartões white label?

Um provedor de Banking as a Service maduro oferece acesso direto a especialistas técnicos, e não apenas a um portal de tickets, com SLAs claros para incidentes críticos que afetem a disponibilidade dos cartões. Além do suporte reativo, o provedor precisa disponibilizar documentação atualizada, ambientes de sandbox para testes de novas funcionalidades e acompanhamento proativo em mudanças regulatórias que impactem a operação, como atualizações de requisitos do Banco Central ou novas versões do PCI DSS.

Para avaliar esse suporte, vale observar a qualidade da documentação pública, a experiência de outros clientes e a clareza dos SLAs propostos em contrato.