Crédito Embedded: Decisão Dentro de Qualquer Produto Digital

O crédito está saindo do banco e entrando no momento da necessidade. Um marketplace que antecipa recebíveis no checkout. Um ERP que oferece capital de giro dentro do painel. Um app de delivery que financia o equipamento do entregador. Isso é embedded credit — e a peça central é a decisão de crédito via API, rápida o suficiente para não quebrar a experiência do usuário.

O que é Decisão de Crédito Embedded

Decisão de crédito embedded é a integração de um pipeline de decisão de crédito diretamente dentro de um produto digital, via API. O produto (marketplace, ERP, app) envia dados do solicitante para a API de decisão, que retorna aprovação/negação com condições — tudo em tempo real, sem redirecionamento para site de banco.

Exemplos reais:

• Marketplace — "Pague em 12x" aparece no checkout; a decisão acontece quando o comprador clica
• ERP/SaaS — "Antecipar recebíveis" dentro do painel do lojista; decisão baseada no histórico de vendas
• Super app — "Empréstimo pessoal" dentro do app de transporte/delivery; decisão em segundos
• Plataforma B2B — "Crédito para fornecedores" dentro do portal de supply chain

Diferenças vs crédito tradicional

Requisitos de latência para embedded

A latência em embedded credit é mais crítica que em crédito tradicional — porque o usuário está no meio de outra ação (comprando, pagando, usando o produto):

• Decisão no checkout: p95 < 1.5 segundos (o botão "comprar" não pode travar)
• Pré-aprovação: p95 < 3 segundos (mostrar "crédito disponível" ao abrir o produto)
• Antecipação de recebíveis: p95 < 2 segundos (lojista quer resultado imediato)

Para atingir esses SLAs, as técnicas de otimização são essenciais: paralelização, cache, Decision Cascade.

Arquitetura de decisão embedded

A arquitetura para embedded credit tem requisitos específicos:

• API-first — tudo via REST/gRPC; sem interfaces humanas no fluxo
• Multi-tenant — um motor servindo múltiplos parceiros, cada um com suas políticas
• Idempotência — a mesma solicitação deve retornar o mesmo resultado (retries do parceiro não devem gerar decisões diferentes)
• Webhooks — notificar o parceiro assincronamente quando decisões complexas (análise manual) são concluídas
• White-label — a decisão é do parceiro (marketplace, ERP), não do motor

Dados do parceiro como diferencial

O maior diferencial do embedded credit é o acesso a dados transacionais do parceiro que bancos tradicionais não têm:

• Marketplace — volume de vendas, ticket médio, avaliações, taxa de devolução, tempo na plataforma
• ERP — faturamento, contas a receber, estoque, sazonalidade, clientes ativos
• Super app — frequência de uso, valor médio de transação, tempo como usuário

Esses dados, combinados com dados tradicionais (bureau, score), criam modelos de scoring mais preditivos para o contexto específico — um lojista com 2 anos de vendas estáveis no marketplace é um risco diferente do que seu score de bureau sugere.

Pipeline de decisão embedded

1. API call do parceiro — com dados do solicitante + dados transacionais
2. Enriquecimento — consultar bureau + validar CPF/CNPJ (em paralelo)
3. Score híbrido — combinar score de bureau com score transacional do parceiro
4. Política por parceiro — cada parceiro pode ter políticas diferentes (apetite de risco, produto, limite)
5. Decisão + condições — aprovado com limite X, taxa Y, prazo Z
6. Response JSON — retorna decisão estruturada para o parceiro renderizar no produto

Multi-tenancy: um motor, muitos parceiros

Em embedded, o mesmo motor serve múltiplos parceiros. Cada parceiro tem:

• Suas próprias políticas de crédito
• Seus próprios limites e condições
• Seu próprio apetite de risco
• Suas próprias integrações de dados

A governança precisa garantir isolamento: parceiro A não vê dados ou políticas do parceiro B.

No Decision Stack™

Como a Sinky suporta embedded credit

A Sinky é API-first: o Sinky Studio permite criar pipelines de decisão por parceiro, cada um com suas regras e modelos. O Sinky Consulta ingere dados transacionais do parceiro via API e combina com bureaus para scoring híbrido. Latência p95 < 1.5s para decisões no checkout. Multi-tenancy nativo com isolamento total entre parceiros.

Perguntas frequentes

O que é decisão de crédito embedded?

Integração de decisão de crédito via API dentro de produtos digitais (marketplaces, ERPs, apps). O usuário solicita crédito sem sair do produto.

Diferença entre embedded credit e BaaS?

BaaS é infraestrutura bancária como API. Embedded credit é a oferta de crédito dentro de um produto não-financeiro, que pode usar BaaS como backend.

Requisitos de latência?

p95 < 1.5s para checkout, p95 < 3s para pré-aprovação. Mais rigoroso que crédito tradicional porque o usuário está no meio de outra ação.