Finalmente, começa a valer a etapa inicial do Open Banking, obrigatória para conglomerados e opcional para demais instituições financeiras, mas que já encontra adesão significativa por parte de diversas Fintechs.
Trata-se, na verdade, da segunda fase de implementação do projeto, mas da primeira que traz impactos práticos para a população em geral e que foi capaz de levar o assunto para a grande imprensa, finalmente popularizando o termo a partir da promessa de maiores oportunidades de competitividade no setor financeiro (sobretudo na oferta de crédito e na possibilidade de portabilidade).
Para o compliance PLDFT, o open banking será um enorme desafio para as instituições receptoras de dados, conforme definidas pela Resolução Conjunta N.º 1 do ME/Bacen.
Em resumo, o open banking obriga as instituições financeiras a padronizar seus registros de dados e a desenvolver plataformas de compartilhamento seguras para que os clientes possam – mediante formalização do consentimento – solicitar a transferência desses dados para outras instituições financeiras.
Para fins de prevenção à lavagem de dinheiro, há dois cenários possíveis.
No primeiro cenário, a instituição receptora de dados já possuiu algum contato com o cliente que solicitou o compartilhamento de dados. Nesse caso, alguns “deveres” de PLDFT podem ser “acionados” no momento da recepção desses dados.
O primeiro, claramente, diz respeito à completude e atualidade do cadastro para fins de KYC. Aqui, algumas situações interessantes podem surgir: o cliente pode ter um endereço adicional previamente desconhecido, um outro emprego, um cônjuge, um relacionamento não mapeado com PEP, etc. Mas esse é certamente o menor dos problemas.
O grande ponto desafio do open banking para fins de PLDFT estará no compartilhamento de dados relativos ao histórico de operações do cliente junto à instituição transmissora de dados.
De acordo com a Circular 4015 do Bacen, que disciplina o open banking, poderão ser objeto de compartilhamento um vasto complexo de dados que podem configurar o histórico de transações de determinado cliente, por exemplo: uso de serviços de contas, programas de benefícios, pacotes de tarifas, produtos de crédito, histórico de transferências e pagamentos de boletos, entre outros.
Esses dados deverão ser levados em consideração no histórico de determinado cliente e em sua avaliação de risco o que significa, na prática, que após ter acesso a dados complementares do comportamento de determinado cliente, a instituição receptora poderá alterar a classificação de risco anteriormente atribuída a ele.
Por isso é muito recomendável que as instituições receptoras façam um verdadeiro “registro” da recepção dos dados compartilhados como um turning point na análise de risco de cada cliente – inclusive para preservar a responsabilidade pretérita de seus analistas de KYC.
Isso porque os novos dados poderão aumentar o grau de risco anteriormente atribuído. Em alguns casos, a IF receptora poderá até mesmo chegar à conclusão que teria mudado o acesso ou o preço de determinados produtos a determinados clientes se já possuísse esses dados à época.
De fato, o open banking não cria deveres retroativos (imagine como o sistema ficaria esquizofrênico se uma IF receptora percebesse em 2021 que poderia ter comunicado ao COAF determinada operação realizada em 2019 com base em dados recebidos apenas em… 2021).
Se não há o dever de fazer comunicações retroativas com base nos novos dados recebidos, há, certamente:
- o dever de reavaliar o risco do cliente com base nos novos dados cadastrais e transacionais recebidos;
- Essa reavaliação também poderá estar sujeita a critérios objetivos definidos na ABR da instituição receptora (tipo de produto solicitado, valor, volume de dados compartilhados, etc.)
- Idealmente, havendo a necessidade de reavaliar o risco do cliente de forma abrangente, a IF receptora poderá realizar uma reavaliação retrospectiva “somando” as informações a que já tinha acesso com as novas recebidas em função do open banking e identificar novos padrões de comportamento e desvios que não puderam ser antes mapeado. Trata-se, certamente, de solução que vai exigir muita conversa entre o time de PLDFT e o de análise de dados.
- havendo mudança de classificação de risco (para pior), a oferta de produto solicitada pelo cliente deve se submeter à análise humana sobre a pertinência e capacidade da IF receptora em tratar aquele novo risco nos termos de sua ABR
- por fim, em termos de relatório de efetividade, esses novos dados poderão dar um bom parâmetro sobre a capacidade da IF em fazer boas avaliações de risco, de acordo com os dados a que teve acesso. Se houver muitas alterações na classificação em decorrência do open banking, isso poderá deixar claro que há necessidades de melhoria nas etapas iniciais de KYC.
No segundo cenário, a instituição receptora não tinha contato com o cliente e passa a ter acesso aos dados daquela pessoa em função de um compartilhamento viabilizado pelo open banking.
Nesse caso, como o compartilhamento de dados está restrito ao conjunto estritamente autorizado pelo cliente à instituição transmissora, a IF que receber os dados estará a princípio desobrigada de ir além desses dados para fazer uma oferta de produto – sendo certo que, havendo contratação, ela terá o prazo regulamentar da 3978 para completar o cadastro e fazer a avaliação completa de risco.
Conforme novos problemas surjam, na prática, traremos mais assuntos sobre Open Banking e PLDFT para o Blog!
A velocidade com que os dados forem atualizados dirá o tom das análises de riscos. Bom artigo!
CurtirCurtido por 1 pessoa