Qual modo de integração do Shufti é o ideal para sua infraestrutura? API, SDK e cliente web explicados.

De acordo com o relatório State of the API 2024 da Postman, 43% dos desenvolvedores identificam a integração de APIs como a tarefa de desenvolvimento que mais consome tempo. Para equipes que adicionam verificação de identidade a um produto regulamentado, a escolha errada de integração não apenas atrasa a entrega, como também cria lacunas de conformidade que são caras para corrigir posteriormente.

A Shufti oferece cinco modos de integração distintos, cada um projetado para uma combinação diferente de requisitos técnicos, restrições de implantação e cronogramas de entrada em produção. Este guia mapeia cada modo para o cenário em que ele melhor se encaixa, para que sua equipe possa tomar a decisão uma única vez e implementar a solução.

Por que o SDK ou o binário da API não atingem o objetivo?

A maioria dos conteúdos sobre verificação de identidade voltados para desenvolvedores apresenta a decisão de integração como binária: SDK ou API. Essa abordagem ignora três outros modos que existem justamente porque nem todo produto é um serviço de backend e nem toda equipe dispõe de semanas de tempo para desenvolvimento.

A arquitetura de integração da Shufti é construída em torno da distribuição real de produtos que precisam de verificação: aplicativos móveis nativos, fluxos de integração baseados na web, soluções de conformidade sem código e implantações corporativas com requisitos de soberania de dados. Cada modo atende a um desses contextos. A API RESTful não é inerentemente melhor que o Cliente Web; ela é mais adequada para um tipo específico de equipe que desenvolve um tipo específico de produto.

Os Cinco Modos de Integração de Shufti

1. API RESTful

A API RESTful da Shufti oferece ao seu backend controle total sobre o fluxo de trabalho de verificação. Seu servidor envia uma solicitação de verificação, a Shufti a processa e os resultados são retornados de forma assíncrona via webhooks (payloads HTTP POST enviados ao seu endpoint assim que a verificação for concluída). O mesmo endpoint da API abrange todos os produtos da Shufti: verificação de documentos, reconhecimento facial, AML screening, KYB e muito mais.

Use esta opção quando: você precisar de verificação servidor a servidor, processamento em lote ou forte integração com sua camada de orquestração existente. Engenheiros de backend em empresas de fintech e serviços financeiros geralmente escolhem este caminho quando a lógica de verificação precisa estar dentro de seu próprio sistema de gerenciamento do ciclo de vida do usuário, em vez de no lado do cliente. O esforço técnico é o maior dos cinco modos, mas o grau de controle também. Mais de 83% das cargas de trabalho empresariais dependem de APIs para comunicação de dados e automação.E a API da Shufti foi criada para funcionar dentro dessa infraestrutura desde o primeiro dia.

2. SDKs para dispositivos móveis

SDKs móveis da Shufti Estão disponíveis para Android, iOS, Flutter, React Native e Cordova. Elas gerenciam a captura de documentos, a detecção de vivacidade e a biometria facial diretamente no dispositivo, enviando os resultados processados ​​para o pipeline de verificação da Shufti.

Use isso quando: você estiver criando um aplicativo móvel nativo e a qualidade da captura biométrica for uma prioridade. Os SDKs para dispositivos móveis acessam diretamente o pipeline da câmera do dispositivo, o que significa que podem detectar ataques de injeção de câmera e de apresentação em um nível que os canais baseados em navegador não conseguem alcançar. Isso está alinhado com os princípios de garantia de autenticidade em NIST SP 800-63Bque reconhecem o acesso nativo ao dispositivo como o canal mais robusto para verificação biométrica. O SDK cuida da experiência do usuário na captura; seu aplicativo gerencia o fluxo da sessão.

3. Cliente Web (Página de Verificação Personalizada / iFrame)

O cliente web hospedado da Shufti é um fluxo de verificação pré-construído que você incorpora em uma sessão do navegador por meio de um iFrame. Shufti O sistema gerencia a interface do usuário, a captura de documentos e dados biométricos e a entrega dos resultados. Você recebe um webhook quando a verificação é concluída, sem precisar criar ou manter a interface de verificação por conta própria.

Use esta opção quando: você precisar de um fluxo de integração baseado na web e quiser evitar a criação e manutenção de uma interface de usuário de verificação. Este é normalmente o caminho mais rápido para produtos web: a integração leva dias em vez de semanas, e as obrigações de tratamento de dados são limitadas. Artigo 32 do RGPD são gerenciadas pelo Shufti e não é necessário compilar nenhum SDK para dispositivos móveis. O esforço técnico é de baixo a médio.

4. Construtor de Jornadas

Construtor de jornadas é o configurador de fluxo de verificação sem código da Shufti. Equipes de conformidade e líderes de operações podem montar fluxos de trabalho de verificação em várias etapas (verificação de documentos, reconhecimento facial, AML screening, verificação de endereço) a partir de uma interface visual, sem escrever uma única linha de código.

Use esta opção quando: você precisar implantar ou iterar em um fluxo de verificação rapidamente e a capacidade de engenharia for a restrição, não a viabilidade técnica. Também é a escolha certa para equipes que precisam de vários fluxos específicos para cada mercado: diferentes países, diferentes tipos de documentos, diferentes listas de vigilância de AML, todos configuráveis ​​independentemente. Biblioteca Journey Builder Inclui fluxos pré-configurados que abrangem mais de 30 mercados. Tempo de implementação: de algumas horas a um dia para a primeira implantação.

5. No local

A implementação On-Premises da Shufti executa toda a pilha de verificação dentro da sua própria infraestrutura. Nenhum dado de verificação sai do seu ambiente. A mesma interface de API RESTful se aplica e você mantém o controle total sobre a camada de computação, a residência de dados e o registro de auditoria.

Use esta opção quando: a soberania dos dados for um requisito fundamental. Bancos e instituições financeiras em jurisdições com rígidas exigências de residência de dados, ou empresas sujeitas a estruturas setoriais específicas que restringem a transferência de dados para a nuvem, utilizam este caminho. O tempo de implementação é o mais longo entre os cinco modos, mas o nível de segurança também é o mais alto: a exposição de dados na nuvem é completamente eliminada.

Como escolher o modo certo: um guia prático

Duas perguntas reduzem rapidamente as opções.

• Primeiro, onde seu produto está hospedado? Aplicativos móveis nativos utilizam o SDK para dispositivos móveis. Produtos baseados na web utilizam, por padrão, o Cliente Web ou a API RESTful. Equipes sem tempo disponível para desenvolvimento começam pelo Journey Builder. Empresas regulamentadas com requisitos de residência de dados precisam de uma solução On-Premises.
• Em segundo lugar, quanto tempo de engenharia está disponível? Se o cronograma for medido em horas, o Journey Builder é a opção mais realista. De dias a uma semana: Cliente Web ou API. De uma a duas semanas: API ou SDK para dispositivos móveis. Implantação empresarial sem prazo definido: On-Premises.

As equipes que integram o KYC (Conheça Seu Cliente) a um produto financeiro geralmente começam com o Cliente Web para uma implementação mais rápida e em conformidade com as normas, migrando posteriormente para a API assim que o fluxo de trabalho principal estiver comprovado. Um guia mais abrangente para o planejamento desse ciclo de vida está disponível em [link para o guia]. Integração KYC Estratégias para uma integração tranquila e em conformidade com as normas.

Utilizando vários modos em conjunto

Utilizar mais de um modo de integração do Shufti em um único produto é comum e previsto na arquitetura. Um aplicativo de serviços financeiros pode executar o Web Client para integração via navegador, o SDK Mobile dentro do aplicativo nativo e a API RESTful para verificação de AML em segundo plano, com os três conectados à mesma plataforma, painel de controle e dados de conformidade. Para uma análise mais aprofundada de como a camada de API funciona dentro de um contexto mais amplo, consulte [link para a documentação]. serviços de verificação de identidade pilha, veja API KYCO que é, como funciona, integração e casos de uso.