API de Assinatura Digital para Fintechs e Bancos Digitais

Em uma fintech, a assinatura não é uma formalidade no fim do fluxo: ela é o ponto onde a operação de crédito se torna juridicamente exigível e onde o onboarding vira uma conta de verdade. Uma API de assinatura digital para fintech precisa entregar muito mais do que um clique em "li e concordo": precisa de identidade forte, prova jurídica auditável, integração em tempo real com o core banking e segurança no nível exigido por reguladores. Este guia mostra como a API da SignDocs se encaixa em fluxos de CCB, contratos de crédito, abertura de conta e termos de adesão.

O contexto regulatório brasileiro é exigente, e com razão: quando você emite uma CCB (Cédula de Crédito Bancário) ou um contrato de financiamento e o tomador entra em inadimplência, o que sustenta a execução do título é a sua capacidade de provar, sem margem para dúvida, quem assinou, quando, de onde e com qual nível de garantia de identidade. Assinatura fraca significa risco de impugnação; assinatura forte com trilha de evidências significa um ativo recuperável.

Se você ainda está mapeando o terreno, vale começar pelo panorama geral em nosso guia sobre API de assinatura digital. Aqui, focamos no recorte de fintechs e bancos digitais, com um fluxo concreto de onboarding e crédito do começo ao fim.

Documentos que uma fintech precisa assinar

Antes de falar de tecnologia, vale enumerar o que de fato passa por assinatura no dia a dia de uma instituição financeira digital. Cada documento tem um perfil de risco diferente, e isso vai direcionar o nível de autenticação que você aplica.

• CCB e contratos de crédito: empréstimo pessoal, crédito consignado, financiamento, antecipação de recebíveis. São os documentos de maior risco e maior valor de exigibilidade.
• Abertura de conta: contrato de conta de pagamento, ficha cadastral, autorização para consulta de bureaus.
• Termos de adesão e contratos de produto: cartão de crédito, seguro, investimentos, programas de cashback.
• Aditivos e renegociações: repactuação de dívida, alteração de limite, portabilidade.
• Cessão e garantias: termos de cessão de crédito, alienação fiduciária, aval e fiança.
• Documentos LGPD: consentimento para tratamento de dados e comunicações.

O erro comum é tratar todos esses documentos com o mesmo nível de assinatura. Um termo de cashback de baixo risco não precisa de biometria facial; uma CCB de R$ 80 mil sem garantia, sim. A boa arquitetura é graduar a autenticação por risco — e a API precisa permitir isso de forma declarativa.

O que uma fintech exige de uma API de assinatura

Fluxos financeiros impõem requisitos que vão além da assinatura comum. Resumimos abaixo as cinco capacidades que separam uma API genérica de uma que aguenta o ambiente bancário.

1. Identidade forte e combinável

Para crédito, a pergunta não é "o documento foi assinado?", mas "como provo que foi exatamente esta pessoa?". A SignDocs trabalha com métodos combináveis: BIOMETRIC_LIVENESS e BIOMETRIC_MATCH (prova de vida e conferência facial), OTP_CHALLENGE (código por SMS ou e-mail), CLICK_ACCEPT (aceite clickwrap) e DIGITAL_SIGN_A1 (o passo de assinatura com certificado ICP-Brasil — acionado pelo perfil DIGITAL_CERTIFICATE —, cobrindo A1 em arquivo e A3 em token). Esses métodos se agrupam em perfis de autenticação — como BIOMETRIC_PLUS_OTP — aplicados conforme o risco.

2. Evidence pack para exigibilidade jurídica

A SignDocs gera, ao final de cada transação, um evidence pack em container PKCS#7/CMS (arquivo .p7m) com a trilha de auditoria append-only completa: hash SHA-256 do documento, carimbos de hora do servidor (timestamps ISO-8601 registrados pelos próprios servidores SignDocs), geolocalização, IP e dispositivo, e os artefatos dos métodos de autenticação usados (resultado da biometria, confirmação de OTP, dados do certificado). Para assinaturas com certificado ICP-Brasil, inclui a cadeia de certificados nos padrões PAdES (para PDF) e CAdES (para qualquer arquivo), no nível baseline (PAdES-B / CAdES-B). É esse pacote que você anexa a uma execução judicial da CCB. Veja os detalhes em evidence pack e prova jurídica via API.

3. Integração em tempo real com o core banking

O desembolso não pode esperar alguém abrir um painel para conferir se a CCB foi assinada. A SignDocs envia webhooks (HTTPS POST com assinatura HMAC-SHA256, idempotência e retry com backoff exponencial) para que seu core banking reaja a eventos como TRANSACTION.COMPLETED e libere o crédito automaticamente. A mecânica completa está em webhooks e eventos da API de assinatura.

4. Segurança no nível de regulados

A autenticação da API é via OAuth2 client-credentials com token bearer (JWT assinado em ECDSA ES256/ES384, chaves em HSM/KMS). Para clientes enterprise e ambientes regulados — incluindo cenários BACEN e Open Finance — há suporte a mTLS (TLS mútuo), que autentica ambas as pontas no nível de transporte. Detalhamos a configuração em mTLS e segurança enterprise.

5. LGPD e escala

A SignDocs é LGPD-first, com endpoints para atender aos direitos do titular, e roda em infraestrutura multi-região na AWS (sa-east-1 e us-east-1) — preparada para o volume de uma operação que processa milhares de assinaturas por dia. O diferencial brasileiro é ser nativa em ICP-Brasil, com produto e suporte em português, e não a alegação de que dados nunca saem do país.

Níveis de autenticação por risco da operação

A decisão central de um time de crédito é mapear cada tipo de documento ao perfil de autenticação adequado. Mais segurança reduz o risco de impugnação, mas adiciona fricção ao onboarding — o equilíbrio depende do valor e da natureza da operação. A tabela abaixo é um ponto de partida prático.

Exemplo de fluxo: onboarding com crédito em uma fintech

Vamos amarrar tudo em um cenário concreto: um cliente solicita um empréstimo pessoal pelo app da fintech. O fluxo passa por abertura/validação de conta e culmina na assinatura da CCB que libera o desembolso.

Passo 1 — Onboarding embutido no app

Para o termo de conta e o consentimento LGPD, o ideal é a Assinatura Expressa: uma única chamada a POST /v1/signing-sessions devolve uma sessão que pode ser embutida como widget dentro do próprio app, sem tirar o usuário do fluxo. O usuário confirma o OTP e faz a prova de vida ali mesmo.

Passo 2 — Emissão e assinatura da CCB

Aprovado o crédito pelo seu motor de decisão, você gera a CCB e cria um envelope com perfil de autenticação mais forte. Para crédito de alto valor com avalista, o envelope brilha: ele suporta múltiplos signatários com ordem sequencial de assinatura.

Passo 3 — Webhook libera o desembolso

Quando todos assinam, a SignDocs dispara ENVELOPE.ALL_SIGNED para o seu endpoint. Seu core banking valida a assinatura HMAC, registra a operação no ledger, arquiva o evidence pack e aciona o desembolso PIX — tudo de forma assíncrona, sem intervenção manual.

Qual superfície de API usar em cada caso

A SignDocs oferece duas superfícies complementares, e a escolha certa reduz a complexidade do seu time:

• Assinatura Expressa / Signing Sessions (POST /v1/signing-sessions): uma chamada gera checkout hospedado ou widget embutido. Ideal para onboarding de conta, termos de adesão e assinaturas de signatário único dentro do app.
• API Transacional (envelopes): ciclo de vida completo, múltiplos signatários, ordem de assinatura, aditivos. Ideal para CCB com avalista, contratos de crédito complexos e fluxos B2B.

Há SDKs oficiais para TypeScript/Node, Python, Go, Java, PHP e C#/.NET, então o time de engenharia integra na linguagem do core. Para outras stacks, a API REST é agnóstica de linguagem e funciona via cURL/HTTP puro.

Padrões de integração no core banking

Algumas práticas tornam a integração resiliente em um ambiente que não tolera perda de eventos nem dupla liberação de crédito.

Idempotência de ponta a ponta

Webhooks operam com semântica de entrega "pelo menos uma vez", então o mesmo TRANSACTION.COMPLETED pode chegar duas vezes. Sua rotina de desembolso deve ser idempotente: use o event_id (ou o transaction_id) como chave de deduplicação antes de movimentar qualquer valor. Liberar crédito duas vezes para o mesmo contrato é um incidente financeiro, não só um bug.

Reconciliação como rede de segurança

Mesmo com retry e DLQ, mantenha uma rotina periódica de reconciliação que consulta o status das transações pendentes pela API. Webhooks são o caminho primário; a reconciliação cobre a cauda de falhas raras sem que nenhuma CCB assinada fique presa em "pendente" no seu sistema.

Persistência durável do evidence pack

O PDF assinado e o .p7m precisam viver por anos — frequentemente além do prazo do contrato. Arquive-os em armazenamento durável com retenção e, idealmente, imutabilidade (WORM). Para verificar a integridade a qualquer momento, qualquer parte pode usar o verificador público de assinatura.

Respeito à LGPD nos dados de identidade

Biometria é dado pessoal sensível. Trate captura, transmissão e retenção sob a ótica da LGPD, com base legal clara (execução de contrato, prevenção à fraude) e ciclo de vida definido. A API expõe endpoints para atender aos direitos do titular.

Além do crédito: outros fluxos da operação

A mesma API que assina sua CCB resolve fluxos adjacentes da empresa: contratos de trabalho e admissão digital quando sua fintech contrata em escala, assinatura white-label sob a sua própria marca quando você opera um modelo de plataforma ou embute serviços financeiros em terceiros, e documentos fiscais e societários no fluxo de contabilidade e compliance interno.

Perguntas Frequentes