Melhor Software de Integração para Bancos: 8 Critérios a Considerar

Última atualização: setembro de 2026

O melhor software de onboarding para bancos é a camada que executa as verificações de identidade do banco, e não apenas uma das verificações. Ele orquestra os provedores de KYC, KYB e verificação de identidade que o banco já usa, direciona cada solicitante para mais verificações apenas quando o risco justifica e reduz quando não é necessário, além de tomar e explicar cada decisão de onboarding. Ele envia para um revisor apenas as solicitações que não consegue decidir, com o contexto necessário para a tomada de decisão, e deixa um registro que um auditor pode acompanhar. A maneira mais confiável de diferenciar os produtos nesses pontos é testá-los com suas próprias solicitações anteriores antes de assinar o contrato.

Este guia apresenta oito critérios para a escolha de um software de onboarding, cada um com as perguntas a serem feitas ao provedor e como se parece uma resposta fraca, seguido por um teste para realizar em suas próprias solicitações e uma tabela de avaliação para reutilizar.

Resumo rápido (TL;DR)

• Escolha o software de onboarding que orquestra seus provedores existentes, direciona os solicitantes para mais ou menos verificações de acordo com o risco, decide e explica cada solicitação e mantém a fila de revisão manual limitada apenas aos casos que uma pessoa precisa ver.

• Avalie as aprovações do software pelo que aconteceu com as contas depois, e não apenas pela taxa de aprovação. A taxa de aprovação é um apetite ao risco que o banco define.

• A regra do Programa de Identificação de Clientes (CIP) do banco, 31 CFR 1020.220, define a base que o registro deve comprovar: nome, data de nascimento, endereço e um número de identificação obtido antes da abertura da conta, com a identidade verificada sob procedimentos baseados em risco.

• A supervisão continua com o banco. As diretrizes interagências de junho de 2023 sobre relacionamento com terceiros estão em vigor e tiveram proposta de substituição em 11 de setembro de 2026 (status em 29 de setembro de 2026). O programa de terceiros de um banco cobre a plataforma e todos os provedores por trás dela.

• Teste cada candidato reproduzindo suas próprias solicitações anteriores e teste em tempo real um provedor que você nunca usou em uma fatia do tráfego.

• A Oscilar escreveu esta lista e comercializa uma plataforma de risco e onboarding. Os critérios não mencionam nomes de provedores.

A resposta curta: como um banco deve escolher um software de onboarding

Um banco deve escolher o software de onboarding que orquestre seus provedores de identidade, KYC e KYB em um único fluxo, direcione cada solicitante para mais ou menos verificações de acordo com o risco, aprove, recuse ou encaminhe cada solicitação com um motivo declarado, mantenha a fila de revisão manual pequena e deixe um registro pronto para auditoria de cada decisão. A forma de confirmar esses pontos é simular uma amostra de suas próprias solicitações passadas em cada candidato antes de assinar, pois uma demonstração mostra o que o software pode fazer em geral, enquanto suas solicitações mostram o que ele faz por você.

O software de onboarding é importante porque uma verificação de KYC responde a uma pergunta mais estreita do que aquela que o banco precisa decidir. Uma verificação de KYC confirma que uma identidade declarada existe e corresponde aos seus documentos em um determinado momento. Ela não estabelece a intenção nem comprova que a identidade não foi criada especificamente para passar na verificação. Decidir o que fazer com um solicitante que passa é tarefa do software de onboarding.

A Oscilar escreveu esta lista e comercializa uma plataforma de risco e onboarding. A Oscilar orquestra verificações de identidade de terceiros, KYC e KYB, não sendo ela própria uma provedora de dados ou verificação. Os critérios abaixo não mencionam provedores ou produtos, e uma seção posterior aplica os mesmos critérios à Oscilar.

Este guia aborda a escolha do software de onboarding como um todo. Para as camadas separadas de detecção de fraudes na abertura de contas, e o que cada camada pode ou não ver, leia nosso guia sobre a estrutura de prevenção de fraudes na abertura de contas.

O que o software de onboarding faz que um único provedor de verificação não faz

O software de onboarding é a camada de decisão e orquestração da abertura de contas. Ele decide quais verificações executar em cada solicitante, com qual provedor, em que ordem e o que fazer com os resultados. Um provedor de KYC, KYB ou verificação de identidade (IDV) responde a uma pergunta específica sobre um solicitante — como se um nome, data de nascimento e endereço correspondem ou se um documento é autêntico —, e o software de onboarding combina essas respostas com os dados e políticas do próprio banco para tomar uma decisão sobre a solicitação.

Um solicitante que passa em todas as verificações ainda pode ser um fraudador. Um diretor sênior de gestão de risco de fraude em uma empresa de pagamentos descreveu um empregador anterior que deixava os resultados de KYC e KYB totalmente de fora de seus modelos: "Mesmo em minha experiência anterior, na verdade não usávamos nenhum dos fornecedores de kyc ou kyb em nossos modelos porque tínhamos muitos casos em que os fraudadores simplesmente passavam sem problemas por todas as verificações de kyc e kyb." As verificações ainda são importantes, mas a decisão sobre um solicitante que passa por elas deve vir da camada superior.

Na prática, o software de onboarding cobre cinco tarefas que nenhum provedor de verificação individual resolve sozinho:

• Orquestração: acionar cada provedor na ordem definida pelo banco e gerenciar falhas ou expiração de tempo (timeout) de um provedor.

• Fluxo baseado em risco: direcionar cada solicitante para mais verificações, ou simplificar o processo, dependendo do risco.

• Decisão: aprovar, recusar, aplicar verificação extra ou encaminhar cada solicitação, anexando a justificativa.

• Revisão: uma fila e uma visualização do caso para as solicitações que uma pessoa precisa decidir.

• Registro: o que foi verificado, por qual provedor, o que foi decidido e por quê.

Algumas das verificações que o software de onboarding executa são contratadas separadamente. Escolher um provedor de KYB para as verificações da própria empresa é uma avaliação independente com seus próprios critérios, assim como escolher um provedor de verificação de identidade isolado. Onde as identidades sintéticas são o principal risco, a avaliação de softwares de detecção de fraude de identidade sintética é um exercício à parte. O mesmo vale para a avaliação de ferramentas de detecção de deepfakes, quando o risco envolve selfies e vídeos manipulados.

Se você ainda está definindo a estratégia geral, incluindo a jornada do solicitante na abertura de conta, comece com o nosso guia sobre estratégia de onboarding para bancos digitais. Este guia pressupõe que essa abordagem já esteja definida e foca no software que a executa.

Os oito critérios e como usá-los

Os oito critérios acompanham uma solicitação durante o onboarding: orquestrar as verificações, direcionar o solicitante para mais ou menos etapas, tomar a decisão, tratar exceções, gerenciar a fila de revisão, alterar políticas, manter registros e se adequar aos sistemas e à supervisão do banco. Cada critério tem as mesmas três partes: o que é, o que perguntar a um provedor e como se parece uma resposta fraca.

Faça as mesmas perguntas por escrito a todos os provedores e teste cada resposta com suas próprias solicitações anteriores, em vez de dados de demonstração. Vale a pena acertar na escolha logo de primeira, pois o software de onboarding atua em todo o fluxo de abertura de contas e sua substituição é cara. O líder de uma equipe de produtos em uma empresa de pagamentos disse que queria ter certeza antes de escolher, "porque é uma integração enorme e uma iniciativa gigantesca".

1. Ele orquestra seus provedores em vez de substituí-los

O que é: Orquestração é a capacidade do software de acionar os provedores que o banco já usa, na ordem que o banco define, e transformar as respostas deles em um único fluxo. Os bancos já dividem as verificações de identidade entre provedores: um banco descreveu o uso de um provedor para verificar telefone e e-mail e outro diferente para nome, data de nascimento e endereço. Um líder de tecnologia em um banco comunitário disse que as ferramentas de verificação costumavam ser caixas-pretas e que o que procuram agora é um fluxo configurável no qual possam mapear qualquer fonte de dados que queiram acessar durante o processo de KYC. Um vice-presidente sênior de estratégia de crimes financeiros em um grande banco regional disse que esperava uma camada de orquestração onde vários fornecedores de verificação pudessem se conectar e as regras pudessem ser alteradas rapidamente.

A orquestração inclui o cascateamento, em que o software aciona um segundo provedor apenas quando o primeiro não consegue verificar o solicitante. Um diretor sênior de análise de decisão de risco em uma empresa de pagamentos buscava um provedor para atuar no final de uma cascata de dois ou três, cada um acionado apenas quando o anterior falhasse, para aumentar a parcela de solicitantes verificados de forma automatizada. Desenvolver isso manualmente é lento e instável. Um diretor de conformidade em um neobanco para pequenas empresas descreveu passar meses tentando criar um fluxo em cascata entre parceiros de verificação, e bastou um dia em que parte do fluxo de onboarding quebrou para que um engenheiro tivesse que intervir e todas as solicitações fossem para revisão manual.

A taxa de aprovação depende tanto dos dados que o banco envia quanto do provedor para o qual os envia. O mesmo diretor sênior de análise de decisão de risco disse que uma taxa de aprovação muito baixa uma vez se revelou como causa a má qualidade dos dados enviados, e não o provedor. Um software que mostra quais campos foram para qual provedor e o que retornou permite ao banco diferenciar essas duas causas.

O objetivo da orquestração é uma decisão melhor, independentemente do número de provedores. Um líder de risco em um banco regional disse: "Não gosto de ter muitos fornecedores conectados a um processo específico." Um vice-presidente de risco de pagamento, conformidade e operações em uma empresa de pagamentos ponderou o outro lado: "Não quero limitar o número de fornecedores apenas por uma preocupação de conformidade e comprometer a qualidade de nossas decisões, certo?" A orquestração resolve esse impasse colocando uma única decisão acima de quantos provedores o banco precisar.

O que perguntar a um provedor:

• Monte nosso fluxo atual em seu software, incluindo nossos provedores atuais. Quais deles você consegue acionar hoje e como um novo é adicionado?

• Nossa equipe pode alterar a ordem dos provedores ou adicionar uma etapa de cascata sem a necessidade de um lançamento de engenharia?

• Quando um provedor expira o tempo ou fica fora do ar, o que acontece com a solicitação em andamento?

• Para cada solicitação, podemos ver quais campos foram para qual provedor e o que cada um retornou?

Como se parece uma resposta fraca: Um fluxo fixo construído em torno das próprias verificações do provedor, no qual adicionar ou reordenar um provedor exige um projeto de serviços profissionais. Uma taxa de aprovação informada sem visibilidade dos dados que a geraram é outro sinal de alerta.

2. Direciona os solicitantes de acordo com o risco, em ambas as direções

O que é: Direcionamento baseado em risco significa que o software adiciona verificações quando o risco do solicitante exige e remove fricção quando não há necessidade. O gatilho é o risco, que pode surgir tanto depois que uma verificação é aprovada quanto quando ela falha. O diretor sênior de gestão de risco de fraude em uma empresa de pagamentos, citado anteriormente, disse: "Eu gostaria de acionar uma verificação extra quando tiver preocupações de fraude no onboarding, no beneficiário ou na verificação do proprietário, mesmo que passem no kyc."

As próprias verificações devem mudar de acordo com o solicitante. Um gerente de produto técnico que lidera uma reestruturação de KYB em uma empresa de pagamentos descreveu o requisito: "Precisamos que o fluxo de verificação seja dinâmico. Por exemplo, queremos criar diferentes modelos de verificação dependendo do setor, nível de risco, país ou outros parâmetros. Com base nesses parâmetros, devemos ser capazes de acionar um modelo de verificação específico com um conjunto específico de campos ou verificações."

O ajuste de etapas também funciona na direção oposta. Um diretor sênior de análise de fraude em uma instituição de crédito ao consumidor disse: "Acho que se pudéssemos identificar solicitações de baixíssimo risco para reduzir a fricção sob a perspectiva de autenticação, isso nos ajudaria." Verificações extras generalizadas geram custos. Em uma plataforma de empréstimos, os solicitantes que não se qualificavam para um caminho rápido passavam por todas as páginas de requisitos, mesmo quando os dados para a decisão já estavam disponíveis, fazendo com que muitos desistissem do processo.

Uma etapa de verificação extra é um estado no fluxo, e não apenas uma verificação adicional. O diretor sênior de análise de decisão de risco citado no critério 1 disse que, uma vez que o solicitante é direcionado para uma verificação de documento e selfie, o restante do fluxo deve pausar até que ele a conclua, pois executar as verificações restantes é inútil se o solicitante nunca clicar no link.

Alguns clientes legítimos inevitavelmente passarão por verificações extras. Um chefe de risco de fraude de cartão em uma instituição de crédito ao consumidor reconheceu que "haverá chances de, inevitavelmente, termos que aplicar etapas extras a clientes legítimos", por isso a verificação adicional precisa ser fácil de concluir. O diretor sênior de gestão de risco de fraude em uma empresa de pagamentos descreveu o objetivo: "Buscamos tornar essa experiência o mais fluida possível — que é um termo melhor do que 'sem fricção', porque há fricção —, mas fluida do ponto de vista de ser fácil para o usuário concluir o processo."

Controles em camadas baseados em risco são o que as diretrizes de 2021 do FFIEC, Autenticação e Acesso a Serviços e Sistemas de Instituições Financeiras, apoiam. As diretrizes dizem: "A segurança em camadas incorpora múltiplos controles preventivos, de detecção e corretivos, e é projetada para compensar possíveis fraquezas em qualquer controle individual." Também se espera uma avaliação de risco para apoiar as decisões sobre técnicas de autenticação.

O que perguntar a um provedor:

• Mostre um solicitante aprovado no KYC sendo direcionado a mais etapas por causa de outro sinal de risco, e um solicitante de baixo risco pulando uma etapa.

• Onde o fluxo pausa enquanto o solicitante conclui uma etapa extra e o que acontece se ele nunca retornar?

• Podemos definir caminhos de verificação diferentes por produto, tipo de solicitante ou nível de risco sem precisar de um lançamento de engenharia?

• Execute nossas solicitações anteriores em sua política padrão. Quais delas teriam passado por etapas extras e por quê?

Como se parece uma resposta fraca: Uma verificação extra acionada apenas quando uma verificação falha, ou as mesmas etapas adicionais para todo solicitante que sai do caminho rápido. Uma verificação adicional que reinicia a solicitação do início é outro sinal de alerta, pois significa que o fluxo não sabe em que ponto o solicitante está.

3. Ele toma a decisão, e você a avalia pela qualidade das aprovações

O que é: A decisão de onboarding é o resultado gerado pelo software para cada solicitação: aprovar, recusar, direcionar para verificação extra ou encaminhar para uma pessoa, com a justificativa anexada. Softwares que apenas repassam os resultados dos provedores deixam a cargo da equipe do banco fazer cada análise manualmente. O teste prático de explicabilidade é se cada decisão traz códigos de motivo e atributos legíveis para o analista que trabalha no caso e, posteriormente, para o registro.

Avalie essas decisões pela qualidade das aprovações, e não apenas pela taxa de aprovação. O diretor sênior de gestão de risco de fraude em uma empresa de pagamentos disse: "Portanto, definitivamente queremos otimizar não necessariamente apenas as taxas de aprovação, mas também a qualidade dessas aprovações." Uma alta taxa de verificação pode vir de uma definição flexível de "verificado", por isso pergunte como cada provedor no fluxo define uma aprovação e acompanhe as contas aprovadas para ver o que aconteceu com elas.

A própria taxa de aprovação é definida pelo apetite ao risco do banco. Um vice-presidente de transformação de risco em uma credenciadora de cartões disse: "Isso é realmente uma questão de política, certo? ... É um apetite. Aceitamos isso e aquilo; se os estabelecimentos comerciais se desviarem disso, sua taxa de aprovação será a sua taxa de aprovação." Um provedor que promete uma taxa de aprovação mais alta sem perguntar sobre o apetite do banco está descrevendo uma política mais flexível.

O que perguntar a um provedor:

• Para uma amostra de nossas solicitações, mostre cada decisão e os motivos por trás dela, como um revisor os veria.

• Como cada provedor no fluxo define uma aprovação e podemos ver as evidências por trás de cada resultado?

• Podemos acompanhar as contas aprovadas após o onboarding, por segmento, para ver quais aprovações se revelaram fraudes posteriormente?

• Quais decisões o software toma e quais ele deixa para a nossa equipe?

Como se parece uma resposta fraca: Uma pontuação única ou apenas um indicador de aprovação/reprovação sem justificativas. Uma taxa de aprovação oferecida como recurso do produto é outro sinal de alerta, pois a taxa é uma política que o banco define.

4. Ele trata exceções sem enviar tudo para um revisor

O que é: O tratamento de exceções é o que o software faz com uma solicitação que não passa de forma limpa, e nem toda falha deve ir para a fila de revisão. Um líder de risco em uma empresa de remessas disse: "Para falhas de id V, não envie para revisão manual. Porque, mesmo que envie, não há nada que possamos fazer a respeito. Em um caso desses, o cliente deve ser orientado a tentar novamente."

Algumas exceções parecem idênticas superficialmente e precisam de um caminho que as diferencie. O diretor sênior de gestão de risco de fraude em uma empresa de pagamentos disse que quando o birô de crédito não retorna dados sobre um solicitante, ele pode ser um cliente legítimo com histórico de crédito escasso (thin-file), jovem ou recém-chegado ao país, ou alguém que inseriu um nome e data de nascimento fictícios com aparência real. O resultado "sem correspondência" é o mesmo para ambos, portanto o software deve direcioná-lo para verificações adicionais que possam diferenciá-los, em vez de aprovar ou recusar apenas com base na ausência de registro.

O que perguntar a um provedor:

• Quais falhas fazem o solicitante tentar novamente na hora e quais vão para uma pessoa? Nossa equipe pode alterar essa divisão?

• Mostre o caminho para um solicitante sem registro no birô, uma vez para um cliente real com histórico escasso e outra para uma identidade falsa.

• Quando um provedor retorna um erro em vez de um resultado, o que o solicitante vê?

Como se parece uma resposta fraca: Toda falha vai para a revisão manual ou toda ausência de registro é recusada. O primeiro caso transfere o custo de cada exceção para um revisor, e o segundo penaliza bons solicitantes.

5. Ele deixa uma fila de revisão dimensionada para a sua equipe

O que é: A fila de revisão é o conjunto de solicitações que o software não consegue decidir e envia para uma pessoa. Seu tamanho e o tempo que cada caso leva definem quantas pessoas o onboarding precisa e quanto tempo os bons solicitantes esperam. Um diretor sênior de análise de fraude em uma instituição de crédito ao consumidor descreveu o custo: "Portanto, em nosso processo de revisão manual, pausamos as solicitações em tempo real, certo? E isso prejudica nossa taxa de conversão em todas as solicitações que revisamos manualmente porque não trabalhamos aos domingos."

O revisor deve ver tudo o que precisa para decidir em uma única tela, com o motivo pelo qual o caso foi criado. O mesmo diretor sênior disse que a instituição financeira não havia automatizado mais porque suas fontes de dados são isoladas e independentes, exigindo que o revisor acesse vários sistemas separados para analisar uma única solicitação. Um software que reúne o resultado de cada provedor, os dados do próprio banco e o motivo do encaminhamento em um único caso elimina essa etapa.

A aplicação consistente das políticas é um dos principais motivos para deixar o software tomar as decisões que puder. Um vice-presidente de transformação de risco em uma credenciadora de cartões disse: "Os humanos são inconsistentes na aplicação da política, certo? ... Estou cansado em uma quarta-feira e de ressaca em uma sexta-feira, certo? E é aí que provavelmente ganharemos um pouco de eficiência, apenas por ter essa consistência."

O que perguntar a um provedor:

• Para a nossa amostra, quantas solicitações iriam para revisão e por quais motivos?

• Mostre um caso de revisão. Ele exibe o resultado de cada provedor, nossos próprios dados e o motivo da criação do caso em um único lugar?

• Como os casos são priorizados e o que acontece com as solicitações pausadas fora do horário comercial?

• Quando um revisor anula a decisão do software, onde isso fica registrado e nossa equipe de risco pode usar esse dado para ajustar a política?

Como se parece uma resposta fraca: Uma fila que lista solicitações apenas com uma pontuação, deixando para o revisor a tarefa de abrir o portal de cada provedor. Outro sinal de alerta é um volume de revisão que ninguém consegue estimar antes da ativação (go-live).

6. Sua equipe de risco pode alterar políticas e testar as mudanças antes

O que é: O controle de políticas define quem pode alterar as regras de onboarding, com que rapidez e com quais evidências de que a mudança funciona. Se cada alteração exigir um chamado de engenharia, o fluxo fica para trás em relação à fraude que deveria deter, e as equipes de risco deixam de propor melhorias. A equipe de risco deve ser capaz de alterar uma regra, um limite ou um caminho de verificação adicional por conta própria, dentro dos controles definidos pelo banco.

Cada alteração deve ser testada antes de entrar em produção. O teste retrospectivo (backtesting) simula solicitações históricas na política proposta para mostrar o que teria sido decidido. Um teste A/B executa a nova política em uma fatia do tráfego real ao lado da atual, mostrando o desempenho em solicitantes que os dados históricos não cobrem.

O que perguntar a um provedor:

• Quem em nossa equipe pode alterar uma regra e qual aprovação a mudança precisa?

• Mostre uma mudança de política testada retrospectivamente em nossas solicitações históricas, indicando as decisões que teriam mudado.

• Podemos executar uma alteração em parte do nosso tráfego real paralelamente à política atual antes de implementá-la totalmente?

• Como cada alteração é versionada e podemos ver qual versão da política decidiu cada solicitação?

Como se parece uma resposta fraca: Alterações de política enviadas como solicitações ao provedor ou testadas apenas depois que entram em produção.

7. Ele gera o registro que um auditor vai exigir

O que é: O registro para auditoria é a evidência, para cada solicitação, do que foi verificado, por qual provedor, o que o software decidiu e por quê, e quem anulou a decisão. A base que ele deve comprovar é a regra do Programa de Identificação de Clientes (CIP) do banco, 31 CFR 1020.220, que exige que um banco obtenha, no mínimo, antes de abrir uma conta, o nome do cliente, data de nascimento (para pessoas físicas), endereço e número de identificação, e verifique a identidade sob procedimentos baseados em risco. Um chefe de risco e conformidade em uma instituição de crédito imobiliário descreveu a necessidade em termos de governança: "há também a parte de governança que é bastante importante sobre como se tem a supervisão das decisões e das evidências, e como você entrega essas evidências ao regulador".

A origem de cada elemento agora faz parte do registro. Sob duas ordens de isenção, do OCC, FDIC e NCUA em 27 de junho de 2025 e do Federal Reserve Board em 31 de julho de 2025, cada uma com a concordância do FinCEN, os bancos sob essas agências podem obter o TIN de um cliente a partir de uma fonte de terceiros em vez do próprio cliente. A flexibilização é opcional, e o banco ainda deve obter o TIN antes de abrir a conta sob procedimentos escritos baseados em risco, de modo que o software deve registrar a fonte de cada elemento de identificação.

O registro deve ser recuperável sem a necessidade de solicitar a terceiros. Um diretor de controle de qualidade de conformidade de BSA em um banco parceiro (sponsor bank), cujos parceiros fintech coletam dados e documentos no onboarding, perguntou: "Mas como nos sentimos confortáveis não apenas com os dados que eles coletam, mas também com a documentação que estão reunindo?" Para um banco que realiza o onboarding por meio de parceiros, o software deve manter esse registro onde o banco possa visualizá-lo.

Para solicitantes pessoa jurídica, o registro também cobre os beneficiários finais. Sob a regra de due diligence de clientes (CDD) do FinCEN, 31 CFR 1010.230, um banco identifica cada indivíduo que possui 25% ou mais das participações societárias de um cliente pessoa jurídica, mais um indivíduo com responsabilidade significativa para controlar, gerenciar ou dirigir a empresa, e verifica suas identidades sob procedimentos baseados em risco. A forma como um provedor de KYB identifica esses proprietários faz parte da escolha do provedor de KYB, que é uma avaliação separada.

O registro apoia o programa de KYC do banco sem substituí-lo. Para o programa em si, leia nosso guia sobre como construir um programa de conformidade de KYC.

O que o registro deve mostrar para cada solicitação:

• As informações de identificação coletadas e a origem de cada elemento, incluindo qualquer TIN obtido de terceiros.

• Cada verificação executada, indicando o provedor, os campos enviados e o resultado retornado.

• A decisão, a versão da política utilizada e os motivos por trás dela.

• Qualquer verificação adicional e o que o solicitante concluiu.

• Qualquer revisão manual, quem tomou a decisão e por quê, e qualquer anulação da decisão do software.

• Para solicitantes pessoa jurídica, os beneficiários finais identificados e como cada um foi verificado.

O que perguntar a um provedor:

• Recupere o registro completo de uma solicitação decidida há meses, sem abrir um chamado de suporte.

• Podemos exportar o registro em um formato que um auditor consiga ler sem precisar do seu software?

• Para solicitações integradas por meio de um parceiro, onde ficam os dados e documentos do parceiro e podemos visualizá-los?

Como se parece uma resposta fraca: Apenas um indicador de aprovação ou reprovação para cada verificação, com os motivos armazenados nos logs do provedor, ou um registro que o banco só consegue obter enviando uma solicitação por e-mail.

8. Ele se adequa à sua estrutura de sistemas, contratos e programa de supervisão

O que é: Adequação é a compatibilidade do software com os sistemas, contratos de provedores e supervisão que o banco já possui. O software deve se conectar aos sistemas principais do banco, aos seus próprios dados e aos provedores existentes, sem exigir uma mudança total de plataforma do banco. Um gerente de produto de um grande banco descreveu a proposta de um provedor: "A proposta deles era basicamente: 'bem, se você reestruturar todo o seu backend e depois jogar tudo na nossa plataforma, ela fará milagres'. E eu pensei: 'isso é legal, mas nunca faremos isso'."

Substituir um provedor não deve significar reconstruir todo o fluxo. Um proprietário técnico de produto para plataformas de fraude e identidade em um grande banco regional disse: "As aplicações de alguns fornecedores são muito fluidas. Outras podem não integrar bem. Já passamos por cenários em que percebemos que algo não estava integrando corretamente. Tivemos que descartar e mudar para outra coisa." Um software que trata cada provedor como uma etapa substituível permite que o banco descarte um sem afetar o restante do processo.

Os contratos de provedores fazem parte da adequação. Um gerente de parcerias em uma fintech de contas PJ perguntou se poderia extrair dados por meio de uma plataforma mantendo seus próprios acordos comerciais com os revendedores de dados, e um gerente de produto técnico que lidera uma reestruturação de KYB em uma empresa de pagamentos perguntou: "Precisamos de contratos separados com registros individuais? Ou apenas um contrato com você?" Qualquer um dos modelos pode funcionar, desde que o banco saiba qual deles está assinando.

A supervisão permanece com o banco. Um líder de conformidade em uma empresa de pagamentos disse que adicionar uma plataforma entre a instituição e seus provedores não transfere a responsabilidade da supervisão, pois o programa de supervisão de fornecedores da instituição ainda deve cobrir a plataforma e cada provedor parceiro por trás dela. As Diretrizes Interagências sobre Relacionamento com Terceiros: Gestão de Riscos, de junho de 2023, estão em vigor e tiveram proposta de substituição em 11 de setembro de 2026 pelo OCC, Federal Reserve, FDIC e NCUA; até 29 de setembro de 2026, a substituição é uma proposta, com comentários previstos para até 16 de novembro de 2026. A proposta enfatiza a adaptação da gestão de riscos de terceiros ao risco avaliado de cada relacionamento e ao tamanho e complexidade da instituição.

O que perguntar a um provedor:

• A quais de nossos sistemas e provedores você se conecta hoje e o que teríamos que alterar para entrar em produção?

• Se substituirmos um provedor, o que mais no fluxo precisará mudar?

• Podemos manter nossos próprios contratos com provedores, comprar por meio de você ou mesclar os dois caminhos?

• O que você fornecerá para a nossa equipe de risco de terceiros realizar a due diligence sobre a sua empresa e sobre cada provedor por trás de você?

Como se parece uma resposta fraca: Um plano de implantação que começa exigindo a migração de todos os seus dados para a plataforma do provedor. Outro sinal de alerta é um provedor que trata as ferramentas parceiras por trás dele como se estivessem fora da supervisão do banco.

Como testar o software de onboarding em suas próprias solicitações

Para testar o software de onboarding, simule uma amostra de suas próprias solicitações passadas em cada candidato e compare as decisões dele com o que realmente aconteceu com esses solicitantes. O diretor sênior de gestão de risco de fraude em uma empresa de pagamentos explicou por que uma demonstração não é suficiente: "Sabe, é sempre legal quando você entra no site de um fornecedor e vê todas aquelas coisas bonitas que eles podem fazer. Mas aí você testa e pensa: 'bem, o que eles realmente fazem na prática?'"

1. Selecione uma amostra de solicitações passadas com resultados conhecidos. Inclua fraudes conhecidas, bons clientes e solicitações que foram para revisão manual, para que o teste cubra os casos reais que definem o valor do software.

2. Simule a amostra em cada candidato paralelamente ao seu fluxo atual. Um responsável por PLD em uma gestora de ativos descreveu ter feito isso com ferramentas anteriores, em um "ambiente de teste experimental onde pudemos passar alguns de nossos dados antigos e compará-los com as taxas de aprovação que tínhamos com as ferramentas anteriores".

3. Como alternativa, teste um provedor que você nunca usou em uma fatia do tráfego real. Um novo provedor não tem histórico em seus dados para simulação. O diretor sênior de gestão de risco de fraude disse: "Porque obviamente não pode ser um estudo retrospectivo. Portanto, talvez algo mais qualitativo ou algo que tenhamos que plugar e apenas avaliar a partir de uma perspectiva de teste A/B/C."

4. Compare as decisões, a taxa de verificação adicional, o volume de revisão e a qualidade das aprovações. A taxa de aprovação isolada favorece uma definição flexível de verificação, portanto, acompanhe as contas aprovadas na amostra para ver quais delas se revelaram fraudes.

5. Analise o registro de algumas decisões. Verifique se um auditor conseguiria acompanhar cada passo, desde os dados coletados, passando por cada verificação, até a decisão e qualquer anulação manual.

6. Altere uma regra da política e meça o tempo necessário para testar e publicar. O exercício mostra quem pode fazer a alteração, se ela pode ser testada retrospectivamente antes e quanto tempo ela espera pela ação de terceiros.

Onde a Oscilar se enquadra, avaliada pelos mesmos critérios

A Oscilar escreveu este guia, portanto esta seção aplica os oito critérios à Oscilar usando apenas o que as páginas publicadas da Oscilar afirmam. A Oscilar não é uma provedora de dados ou de verificação. Ela orquestra verificações de identidade de terceiros, KYC e KYB em conjunto com os dados da própria instituição.

Sobre orquestração e etapas adicionais (critérios 1 e 2), a página sobre onboarding de consumidores na Oscilar descreve a orquestração de verificações de KYC e verificações avançadas de identidade, conectando os próprios bancos de dados da instituição e fontes de dados de terceiros por meio de um marketplace de parceiros. A Oscilar adiciona inteligência de dispositivos, biometria comportamental e enriquecimento de dados a essas verificações, executa processos de onboarding que se adaptam ao perfil de risco de cada solicitante e oferece verificações adicionais que acionam due diligence aprimorada e etapas extras de verificação quando necessário. O onboarding de empresas funciona da mesma forma, com verificações de KYB no lugar de KYC.

Sobre a decisão, tratamento de exceções e fila de revisão (critérios 3, 4 e 5), a Oscilar combina regras, aprendizado de máquina supervisionado e detecção de anomalias não supervisionada. Sua gestão de casos orientada por IA prioriza os casos de onboarding, oferece uma visão holística de cada solicitante e explica em linguagem natural o motivo pelo qual cada caso foi criado.

Sobre alterações de política (critério 6), uma equipe de risco pode criar processos em uma interface no-code e low-code, testar retrospectivamente um novo processo de onboarding com dados históricos antes de implantá-lo, realizar testes A/B e monitorar falsos positivos, taxas de aprovação e seus próprios KPIs posteriormente. A Oscilar também possui monitoramento automático de modelos abrangendo desvio de dados (data drift), desvio de recursos (feature drift) e desvio de conceito (concept drift), além de KPIs de resultados medidos por segmento.

Sobre o registro para auditoria (critério 7), a Oscilar mantém uma trilha de auditoria completa por decisão com justificativas armazenadas, além de recursos que incluem a supervisão humana por padrão (human-in-the-loop). Sobre adequação (critério 8), a Oscilar é uma plataforma única que abrange onboarding, crédito, fraude e PLD, e a plataforma foi desenvolvida para tomar decisões em menos de 100 milissegundos.

A Oscilar não realiza verificação de documentos nem testes de prova de vida (liveness) por conta própria. Essas verificações vêm dos provedores de verificação de identidade que ela orquestra, por isso pergunte qual provedor um fluxo acionaria para cada verificação e execute o teste acima na Oscilar com a mesma amostra usada para os outros candidatos.

A Oscilar foi incluída no FCC50 de 2026 da Chartis, seu ranking de fornecedores de tecnologia de conformidade e crimes financeiros, com vitórias nas categorias de Customização Low-Code/No-Code e Inovação em IA Agêntica. A Oscilar também é uma parceira preferencial da Nacha para Validação de Contas, Monitoramento de Fraude e Prevenção de Risco e Fraude. Nenhuma dessas conquistas é um ranking específico de softwares de onboarding e nenhuma delas substitui o teste da Oscilar com suas próprias solicitações.

Os oito critérios em resumo

A tabela associa cada critério à pergunta que o testa, à resposta que deve acender um sinal de alerta e ao teste que você deve executar em suas próprias solicitações. Preencha uma vez para cada provedor em sua lista de finalistas.

Perguntas frequentes

O que o software de onboarding para bancos faz que um único provedor de KYC ou verificação de identidade não faz?

O software de onboarding para bancos decide o que fazer com um solicitante, enquanto um provedor de KYC ou verificação de identidade apenas responde a uma pergunta específica sobre esse solicitante. O software aciona cada provedor na ordem definida pelo banco, direciona o solicitante para mais ou menos etapas de acordo com o risco e combina os resultados com as políticas e os dados do próprio banco. Em seguida, ele aprova, recusa, direciona para verificação extra ou encaminha a solicitação com uma justificativa, mantendo o registro de cada decisão.

Quando o software de onboarding deve direcionar um solicitante para verificações extras?

O software de onboarding deve direcionar um solicitante para etapas adicionais sempre que o seu nível de risco exigir, inclusive após uma verificação de KYC aprovada, e não apenas quando uma verificação falhar. Ele também deve simplificar o processo para solicitantes de baixíssimo risco, reduzindo a fricção. Enquanto o solicitante conclui uma verificação extra, o restante do fluxo deve ser pausado, e a etapa adicional deve ser fácil de ser concluída por um cliente legítimo.

O que deve acontecer com uma solicitação que o software não consegue decidir?

Uma solicitação que o software não consegue decidir deve ser enviada a um revisor com tudo o que ele precisa para tomar a decisão em uma única tela: o resultado de cada provedor, os dados do próprio banco e o motivo pelo qual o caso foi criado. Uma falha no envio de selfie ou na verificação de documentos geralmente é melhor resolvida orientando o solicitante a tentar novamente do que enviando-a diretamente para a fila de revisão. Um solicitante sem registro nos birôs de crédito precisa de verificações adicionais que diferenciem um cliente real com histórico escasso de uma identidade fictícia.

O que um auditor vai exigir ver das decisões de onboarding do banco?

Um auditor que analisa o onboarding buscará evidências de que o banco cumpriu seu Programa de Identificação de Clientes sob a norma 31 CFR 1020.220: o nome, data de nascimento, endereço e número de identificação obtidos antes da abertura de cada conta, e como a identidade foi verificada sob procedimentos baseados em risco. Um registro útil mostra, para cada solicitação, o que foi verificado, por qual provedor, o que foi decidido e por quê, e quem anulou a decisão. Para clientes pessoa jurídica, também exibe os beneficiários finais identificados e como cada um foi verificado.

Um banco pode obter o TIN de um cliente a partir de uma fonte de dados em vez do próprio cliente?

Sim, se o banco for supervisionado por uma agência que emitiu uma ordem de isenção. Ordens do OCC, FDIC e NCUA de 27 de junho de 2025 e do Federal Reserve Board de 31 de julho de 2025, cada uma com a concordância do FinCEN, permitem que esses bancos obtenham o TIN do cliente de uma fonte terceirizada em vez do próprio cliente. A flexibilização é opcional, o banco ainda deve obter o TIN antes de abrir a conta sob procedimentos escritos baseados em risco, e o texto da 31 CFR 1020.220 não foi alterado.

Por quanto tempo um banco deve testar um software de onboarding em suas próprias solicitações?

Um banco deve testar o software de onboarding pelo tempo necessário para cobrir solicitações cujos resultados reais sejam conhecidos, incluindo fraudes, bons clientes e casos que foram para revisão. A simulação de solicitações históricas pode ser executada assim que o candidato for conectado, pois esses resultados já estão nos dados do banco. Um teste em tempo real de um novo provedor em uma fatia do tráfego deve ser executado até que as contas aprovadas por ele tenham tempo suficiente para mostrar seu comportamento, o que depende dos produtos e volumes do banco.

Como a Oscilar se sai diante desses critérios?

A Oscilar orquestra verificações de identidade de terceiros, KYC e KYB junto com os dados da própria instituição, não sendo ela própria uma provedora de dados ou verificação, ou seja, ela não realiza verificação de documentos ou prova de vida diretamente. Ela oferece processos de onboarding que se adaptam ao risco de cada solicitante, verificações extras, gestão de casos orientada por IA que explica o motivo de criação de cada caso, testes retrospectivos e testes A/B de mudanças de política. Ela mantém uma trilha de auditoria completa por decisão com justificativas armazenadas e supervisão humana por padrão. Como a Oscilar escreveu este guia, teste-a em suas próprias solicitações da mesma forma que faria com qualquer outro candidato.

O melhor software de onboarding para um banco é aquele que apresenta resultados reais com as próprias solicitações do banco. Ele orquestra os provedores que o banco já usa, direciona os solicitantes para mais ou menos etapas de acordo com o risco, decide e explica cada solicitação, mantém a fila de revisão pequena e deixa um registro que um auditor pode acompanhar. A abordagem da Oscilar para onboarding de consumidores é uma opção para colocar à prova nesse teste, ao lado de qualquer outro candidato.