Última atualização: 29 de agosto de 2026
Principais lições deste artigo
-
Integrar originação de crédito via API exige orquestrar ao mesmo tempo consentimento Open Finance, motor de decisão idempotente e formalização regulatória. Quando essas etapas ficam fragmentadas, o lançamento atrasa e o risco operacional aumenta.
-
A escolha entre SCD e SEP define quem emite o crédito e quem assume o risco de crédito. Essa decisão impacta a arquitetura técnica e os requisitos de compliance.
-
Ter uma máquina de estados bem projetada garante rastreabilidade auditável em cada transição da proposta, desde a captura do consentimento até a emissão da CCB.
-
Usar APIs modulares e licenças SCD de parceiros reduz o tempo de go-to-market de meses para semanas, mantendo a conformidade regulatória.
Checklist de integração: 8 passos para originação de crédito via API
Passo 1: mapeie o modelo regulatório antes de escrever uma linha de código
O primeiro passo é alinhar produto, risco e regulação antes de qualquer desenvolvimento.
Pré-requisitos: definição do produto de crédito, como BNPL, consignado, crédito limpo ou antecipação de recebíveis, e identificação do detentor do risco de crédito.
Partes envolvidas: jurídico, produto e tecnologia.
Resultado esperado: decisão documentada sobre qual licença será utilizada, própria ou de parceiro, e qual modalidade de crédito será ofertada.
Diferença entre SCD e SEP na originação via API
Uma Sociedade de Crédito Direto (SCD) tem licença para conceder crédito com recursos próprios ou de fundos de investimento e emitir instrumentos como a Cédula de Crédito Bancário diretamente. Uma Sociedade de Empréstimo entre Pessoas (SEP) opera como plataforma de intermediação entre credores e tomadores e não assume o risco de crédito no próprio balanço.
Na prática, a escolha entre SCD e SEP define a arquitetura da API. Uma SCD precisa de endpoints para emissão de CCB, gestão de carteira e cessão de recebíveis. Uma SEP requer fluxos de matching entre partes e controles de segregação de recursos. Uma fintech sem licença própria pode operar sob a licença SCD de um parceiro de infraestrutura e acelerar o go-to-market mantendo a conformidade regulatória.
Ponto de atenção: compliance e integração
A Resolução BCB 494/2025 exige que instituições de pagamento não autorizadas solicitem autorização ao Banco Central ou cessem operações, o que torna a escolha de licença uma condição de continuidade do negócio.
A Circular BCB 3.978/2020 exige retenção de informações de risco por dez anos para inspeção do Banco Central.
APIs e logs de produção não devem expor features do modelo de crédito nem dados pessoais excessivos, para evitar violação da LGPD e vazamento de propriedade intelectual do motor de decisão.
Motores de decisão devem operar em modo fail-closed. Quando um bureau ou componente de verificação falha, o sistema deve encaminhar para revisão manual e nunca aprovar por padrão.
Passo 2: como implementar consentimento Open Finance em propostas de crédito
Garantir um fluxo de consentimento robusto é essencial para operar em escala com segurança jurídica.
Pré-requisitos: credenciamento como participante do Open Finance Brasil ou uso da infraestrutura de um parceiro participante direto.
Partes envolvidas: engenharia de backend, produto e DPO.
Resultado esperado: fluxo de consentimento implementado com ciclo de vida completo, incluindo criação, renovação, expiração e revogação, com evidências de auditoria armazenadas.
O Open Finance Brasil processou um volume expressivo de chamadas de API e registrou dezenas de milhões de consentimentos ativos de compartilhamento de dados em 2024, com a API de Portabilidade de Crédito em piloto de produção desde novembro de 2025. Esse volume mostra que o ecossistema suporta originação de crédito em escala, mas exige implementação rigorosa do ciclo de consentimento.
Para garantir essa implementação rigorosa, a recomendação operacional é vincular expiração do consentimento, revisão de permissões e validação de revogação em um único workflow, preservando evidências de auditoria para eventos multipartes. Consentimento e identidade devem ser gerenciados como uma única superfície de controle. Assim, o consentimento permanece explícito, com prazo definido e escopo restrito o suficiente para evitar acesso excessivo a dados durante trocas de informações de crédito.
Dica útil: revogação de consentimento
Implemente a revogação de consentimento como uma operação propagada em toda a cadeia, da instituição de origem ao destino e ao rail de liquidação. Armazene o evento de revogação com timestamp, identificador do consentimento e identidade do solicitante. Nunca processe dados de crédito após a revogação, mesmo que a chamada de API já esteja em trânsito.
Passo 3: arquitetura de máquina de estados para aplicações de crédito
Usar uma máquina de estados bem definida organiza o ciclo de vida da proposta e facilita auditoria e operação.
Pré-requisitos: modelo de dados da proposta definido, banco de dados com suporte a transações ACID e estratégia de idempotência estabelecida.
Partes envolvidas: engenharia de backend e arquitetura de dados.
Resultado esperado: máquina de estados implementada com transições auditáveis, log de eventos imutável e tratamento explícito de estados terminais.
Uma máquina de estados é a estrutura adequada para fluxos de crédito porque o ciclo de vida da proposta possui um conjunto finito e bem definido de estados com transições explícitas e auditáveis. O diagrama abaixo mostra como uma proposta progride desde o rascunho inicial até os estados terminais de desembolso ou cancelamento, evidenciando os pontos de decisão críticos:
RASCUNHO → CONSENTIMENTO_OBTIDO → ANÁLISE_INICIADA → DECISÃO_PENDENTE → APROVADA | REPROVADA | ESCALADA → CCB_EMITIDA → DESEMBOLSADA | CANCELADA Cada transição deve ser persistida dentro de uma transação de banco de dados que adquire bloqueio de linha e insere um evento no log de auditoria. Tentativas de mover a proposta para um estado inválido devem retornar erro explícito de transição ilegal, sem serem silenciadas. Workflows que esgotam tentativas de retry devem chegar a um estado terminal visível e consultável, sem permanecer presos em loops de retry.
Dica útil: idempotência
Derive chaves de idempotência a partir da identidade de negócio mais a intenção da operação, por exemplo,
proposta:{org_id}:{checkout_id}, e não de metadados de transporte como timestamps ou IDs de requisição HTTP. Armazene a chave com restrição de unicidadeUNIQUE(owner_id, idempotency_key)no banco de dados e retorne 409 Conflict quando a mesma chave chegar com payload diferente. Defina janelas de deduplicação entre 24 horas e 7 dias para absorver retries de clientes, timeouts de fila e replays de DLQ.
Passo 4: integre o motor de decisão de crédito via API
Conectar o motor de decisão à máquina de estados permite automatizar análise de crédito com rastreabilidade.
Pré-requisitos: política de crédito documentada, parceiros de score definidos e máquina de estados do passo anterior operacional.
Partes envolvidas: engenharia, risco e produto.
Resultado esperado: decisão automática com reason codes auditáveis, roteamento para revisão humana em casos de risco intermediário e armazenamento separado de evidências brutas e features derivadas.
Um motor de decisão de produção armazena objetos de evidência bruta separados das features de crédito derivadas, de modo que qualquer decisão possa ser exatamente reproduzida. Para garantir essa reprodutibilidade, cada registro de evidência deve carregar identificador de fonte, timestamp de recuperação, referência de consentimento, status de validação e flag de expiração, metadados que permitem reconstruir o contexto exato da decisão original. Em setores regulados como o financeiro, engines de workflow determinísticas são necessárias para coordenar agentes de decisão, pois roteamento probabilístico não atende aos requisitos de trilha de auditoria imutável.
Passo 5: formalize a operação, com emissão de CCB e cessão de recebíveis
A formalização conecta a decisão de crédito à emissão de instrumentos e à estrutura de funding.
Pré-requisitos: proposta no estado APROVADA, licença SCD disponível, própria ou de parceiro, e dados do tomador validados por KYC.
Partes envolvidas: jurídico, engenharia e parceiro de infraestrutura.
Resultado esperado: CCB emitida digitalmente, registrada e vinculada ao identificador da proposta na máquina de estados.
Passo 6: avalie Credit as a Service em relação ao build próprio
Escolher entre construir internamente ou usar Credit as a Service define prazo, custo e foco da equipe.
Pré-requisitos: análise de capacidade interna de engenharia, prazo de go-to-market e orçamento disponível.
Partes envolvidas: CTO, Head de Produto e CFO.
Resultado esperado: decisão documentada sobre modelo de operação.
Construir toda a infraestrutura de crédito internamente exige equipes especializadas em regulação, segurança, integração com bureaus, emissão de instrumentos e gestão de carteira, além de meses de desenvolvimento antes da primeira operação. O modelo Credit as a Service permite que a empresa foque no produto e na experiência do cliente, enquanto o parceiro de infraestrutura fornece módulos pré-construídos, licenças e integrações regulatórias.
A complexidade regulatória e a estrutura do mercado de crédito brasileiro tendem a favorecer quem faz parceria com provedores de infraestrutura em vez de tentar construir de forma independente. O mercado de Embedded Lending na América Latina projeta crescimento relevante até 2033, impulsionado pela expansão do Open Finance, avanços em APIs e demanda por crédito contextualizado.
Passo 7: configure monitoramento, segurança e prevenção de fraude
Monitorar a operação em tempo real protege receita e reduz risco de incidentes e fraudes.
Pré-requisitos: ambiente de produção configurado, SLAs de API definidos e política de resposta a incidentes documentada.
Partes envolvidas: engenharia, segurança e operações.
Resultado esperado: monitoramento em tempo real de latência, taxa de erro e padrões de fraude, com SLA de contenção definido para incidentes confirmados.
SLAs de produção para APIs de dados de risco devem mirar latência p99 abaixo de 800 ms para validação síncrona, disponibilidade de 99,9% e taxa de erro abaixo de 0,5% sob carga. Fraude sintética em operações de crédito digital requer detecção por sinais comportamentais e de dispositivo, como fingerprint, velocidade anômala e correlação de ASN, além de verificações cadastrais.
Dica útil: testes em sandbox
Um sandbox de crédito completo deve retornar casos representativos do mundo real, como proposta aprovada, reprovada, em revisão manual, bureau indisponível e consentimento revogado durante o fluxo. Sandboxes que retornam apenas respostas 200 OK não validam o comportamento do sistema em cenários de falha, que são os cenários que costumam causar incidentes em produção. Defina métricas de aceitação antes do POC, como latência máxima, taxa de match mínima e taxa de erro máxima.
Passo 8: valide critérios de produção antes do go-live
Concluir o checklist de produção reduz risco de incidentes no lançamento.
Pré-requisitos: todos os passos anteriores concluídos, testes de carga executados e revisão de compliance finalizada.
Partes envolvidas: engenharia, produto, jurídico e parceiro de infraestrutura.
Resultado esperado: checklist de go-live assinado com evidências de cada critério atendido.
Critérios de sucesso
-
Rastreabilidade: cada proposta possui trilha de auditoria completa, do consentimento à CCB emitida, com timestamps e identidades registrados em log imutável.
-
Redução de fricção: o fluxo de consentimento e decisão é concluído sem redirecionamentos desnecessários, com revogação propagada em tempo real.
-
Aderência regulatória: KYC, AML e base legal LGPD documentados por operação, retenção de dados configurada conforme Circular BCB 3.978/2020 e motor de decisão operando em modo fail-closed.
-
Idempotência verificada: testes de retry e replay confirmam ausência de operações duplicadas em produção.
-
SLA de contenção: processo de resposta a incidentes de fraude testado e com tempo de contenção definido.
Aplicações e desdobramentos
Com a esteira de originação operacional, você pode expandir para módulos adjacentes que compartilham a mesma infraestrutura de dados e conformidade. Os mesmos componentes, como máquina de estados, consentimento e rastreabilidade, sustentam gestão de risco, formalização e cobrança.
Uma vez que a esteira de originação via API está operacional, ela serve de base para módulos adjacentes. Na gestão de risco, os dados de comportamento de pagamento alimentam modelos de risco dinâmico que ajustam limites e taxas ao longo do ciclo de vida do cliente. Na formalização, a emissão automatizada de CCBs e Notas Comerciais viabiliza a estruturação de FIDCs e a cessão de carteiras para gestoras de fundos. Na cobrança, o mesmo identificador de proposta da máquina de estados conecta o fluxo de originação ao módulo de régua de cobrança, garantindo rastreabilidade ponta a ponta sem retrabalho de integração.
A Celcoin como parceira de infraestrutura de crédito
A Celcoin opera no modelo B2B2C. A empresa não oferece empréstimos diretamente a consumidores, mas fornece a infraestrutura tecnológica para que empresas consigam ofertar produtos de crédito aos seus clientes. Essa arquitetura permite que fintechs, varejistas e ERPs lancem produtos de crédito sem construir toda a stack regulatória e técnica do zero.
A solução de crédito da Celcoin abrange toda a jornada, da originação à cobrança, com APIs modulares, licença SCD própria disponível para parceiros, integração com o Open Finance como participante direto e Iniciadora de Pagamentos e neutralidade em relação às gestoras de fundos. Fintechs, correspondentes bancários, varejistas e ERPs utilizam a infraestrutura da Celcoin para lançar produtos como BNPL, crédito consignado público e privado, crédito com e sem garantia e antecipação de recebíveis.
A tabela abaixo resume as principais funcionalidades da plataforma e o benefício direto que cada uma entrega para sua operação:
|
Funcionalidade da Celcoin |
Benefício para sua empresa |
|
APIs modulares |
Integrações mais rápidas, reduzindo 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 e competitividade. |
|
Distribuição white-label e embutida (embedded) |
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 sua receita com confiança. |
|
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, melhorando 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 melhor cobertura, recursos e velocidade de entrada no mercado. |
FAQ
O que é uma máquina de estados no contexto de originação de crédito via API?
Uma máquina de estados é uma estrutura de software que define todos os estados possíveis de uma proposta de crédito, como rascunho, análise iniciada, aprovada, CCB emitida e cancelada, e as transições permitidas entre eles. Cada transição é registrada em um log de auditoria imutável, o que garante rastreabilidade completa para fins regulatórios e operacionais. Tentativas de mover uma proposta para um estado inválido são bloqueadas com erro explícito, o que evita inconsistências de dados. Essa abordagem é indicada para fluxos de crédito porque o ciclo de vida da proposta é finito, auditável e sujeito a revisão regulatória.
Qual a diferença prática entre SCD e SEP para uma fintech que quer originar crédito?
Uma Sociedade de Crédito Direto permite que a instituição conceda crédito com recursos próprios ou de fundos de investimento, emitindo CCBs diretamente e assumindo o risco de crédito. Uma Sociedade de Empréstimo entre Pessoas atua como plataforma de intermediação, conectando credores e tomadores sem assumir o risco no próprio balanço. Para uma fintech sem licença própria, a alternativa mais rápida costuma ser operar sob a licença SCD de um parceiro de infraestrutura. Esse modelo permite lançar produtos de crédito formalizados sem passar pelo processo de obtenção de licença junto ao Banco Central, que pode levar meses ou anos.
Como o consentimento do Open Finance se integra ao fluxo de originação de crédito?
O consentimento do Open Finance autoriza o compartilhamento de dados financeiros do cliente entre instituições para fins específicos, como análise de crédito. Na prática, o fluxo de originação deve capturar o consentimento antes de qualquer consulta a dados externos, armazenar o identificador do consentimento vinculado à proposta na máquina de estados e monitorar ativamente sua expiração e eventual revogação. Se o consentimento for revogado durante o processamento, o sistema deve interromper o fluxo imediatamente e registrar o evento. A revogação deve ser propagada para todos os participantes da cadeia, instituição de origem, destino e rail de liquidação, com evidências de auditoria preservadas.
Quanto tempo leva para integrar originação de crédito via API usando infraestrutura de parceiro?
O prazo depende da complexidade do produto de crédito, do nível de customização da política de crédito e da maturidade técnica da equipe de engenharia. Com APIs modulares bem documentadas, sandboxes representativos e suporte técnico dedicado, uma fintech com equipe de engenharia estruturada consegue lançar o primeiro produto de crédito em semanas. O principal fator de aceleração é não precisar construir internamente módulos de emissão de CCB, integração com bureaus, conformidade regulatória e gestão de carteira, que, desenvolvidos do zero, podem consumir meses de engenharia.
