Integração do core banking com o goAML: opções de API, SFTP e CSV
Como integrar os sistemas bancários centrais (T24, Finacle, FlexCube) com uma plataforma de comunicações goAML através de API REST, transferência de ficheiros por SFTP ou importação CSV. Inclui um guia de mapeamento de campos.
Qualquer plataforma goAML de comunicações em matéria de prevenção e combate ao branqueamento de capitais e ao financiamento do terrorismo (BC/FT) vale apenas o que valem os dados que a alimentam. O motor de geração de XML mais sofisticado, o modelo de pontuação de risco mais cuidadosamente calibrado e o fluxo de trabalho de conformidade mais bem concebido ficam todos comprometidos se os dados de transacções subjacentes estiverem incompletos, mal formatados ou tiverem sido reintroduzidos à mão, a partir de um relatório do sistema bancário central (core banking), por um analista de conformidade que leu mal um campo de data.
A integração entre o sistema bancário central de um banco e a sua plataforma de comunicações BC/FT é a decisão técnica com mais consequências de toda a implementação. Se for bem feita, a função de conformidade trabalha com dados de transacções exactos, completos e atempados, com um mínimo de intervenção manual. Se for mal feita, a equipa de conformidade passa tanto tempo a validar a qualidade dos dados como na análise de conformidade propriamente dita.
A boa notícia é que os três métodos de integração disponíveis — API REST, transferência de ficheiros por SFTP e importação CSV/Excel — cobrem todo o espectro de capacidades técnicas das instituições financeiras da África Oriental, desde os bancos nativos digitais com sistemas bancários centrais nativos da cloud até às instituições comunitárias com plataformas legadas e infra-estruturas informáticas limitadas.
Por que razão a integração é determinante para a conformidade goAML
GIGO: dados maus à entrada, XML mau à saída
O esquema XSD goAML é rigoroso. Cada documento XML submetido é validado face ao esquema e às regras de negócio específicas de cada país. Um montante guardado no sistema bancário central como cadeia de caracteres com separador de milhares («1,250,000») tem de ser transformado num decimal com exactamente duas casas decimais («1250000.00»). Uma data guardada no formato DD/MM/YYYY tem de passar a YYYY-MM-DD. Um tipo de transacção guardado como código numérico («01» para depósito em numerário) tem de ser mapeado para o valor da enumeração goAML («CASH_DEPOSIT»).
Se estas transformações não acontecerem automaticamente numa camada de integração bem concebida, têm de ser feitas à mão — e a preparação manual dos dados é a origem da maioria dos erros de submissão goAML. Mesmo responsáveis pela conformidade altamente qualificados cometem erros de transcrição quando convertem manualmente dados entre formatos, sob pressão do tempo.
Uma camada de integração robusta executa todas as transformações de forma automática e sistemática. Impõe a qualidade dos dados no ponto de ingestão, antes de os dados entrarem no fluxo de trabalho de conformidade, enquanto a atenção da equipa de conformidade se concentra na análise e não na limpeza de dados.
A reintrodução manual de dados é a origem da maioria dos erros goAML
Nos bancos sem integração automatizada com o sistema bancário central, o fluxo de trabalho típico é o seguinte: a equipa de TI extrai um relatório de transacções do sistema bancário central e entrega-o num ficheiro Excel; o analista de conformidade exporta os dados relevantes, mapeia manualmente os campos para a estrutura XML goAML, preenche um modelo goAML e submete. Cada etapa manual cria oportunidades de erro.
Os erros mais comuns resultantes da reintrodução manual incluem: inversões do formato da data (6 de Março introduzido como 3 de Junho), erros de posicionamento das casas decimais (125 000 KES introduzido como 12 500 KES ou 1 250 000 KES), truncagem do campo do nome, transposição de dígitos do número de conta e divergências nos códigos de moeda. Qualquer destes erros leva o XML submetido a falhar a validação do esquema ou a validação das regras de negócio no portal da unidade de informação financeira (UIF).
A integração elimina a camada de transcrição humana
Uma integração directa entre o sistema bancário central e a plataforma BC/FT significa que os dados de transacções fluem electronicamente, com regras de transformação definidas e aplicadas de forma programática e coerente. O analista de conformidade nunca toca nos dados de transacções em bruto — trabalha com dados de casos já validados e formatados, numa interface estruturada. O seu tempo é dedicado à análise e à avaliação, e não à preparação de dados.
Método de integração 1: API REST
Como funciona
A integração por API REST permite à plataforma BC/FT pedir dados de transacções à camada de API do sistema bancário central, de forma agendada ou desencadeada por eventos. A plataforma BC/FT autentica-se na API do sistema bancário central, pede as transacções que satisfazem critérios específicos (intervalo de datas, tipo de transacção, limiar de montante), recebe a resposta em formato JSON ou XML e mapeia os campos da resposta para o modelo de dados interno da plataforma BC/FT.
Este método suporta o acesso aos dados tanto em tempo real como quase em tempo real. Para a geração de alertas de comunicação de operação suspeita (STR) — em que um padrão de transacções suspeito tem de ser apresentado a um responsável pela conformidade o mais depressa possível depois de ocorrer —, a consulta periódica (polling) da API quase em tempo real, a cada 15 a 60 minutos, proporciona os dados mais actuais.
Para a monitorização do limiar das comunicações de transacções em numerário (CTR), a ingestão por API permite a detecção quase em tempo real, transacção a transacção, face ao limiar equivalente a 15 000 USD, para que as transacções abrangidas possam ser apresentadas para a criação de casos de CTR dentro do prazo de submissão, que termina na sexta-feira da semana.
Sistemas bancários centrais com API REST na África Oriental
O Temenos T24 R20+ inclui o componente T24 API Server, que expõe consultas (enquiries) baseadas em TAFJ como pontos de acesso (endpoints) RESTful. A obtenção de dados de transacções exige uma definição de enquiry no T24 que especifique os campos e os critérios de filtragem, exposta através do API Server. O T24 API Server suporta a autenticação OAuth 2.0 por credenciais de cliente (client credentials).
As versões Infosys Finacle 10 e 11 incluem o Finacle Connect API Gateway, que disponibiliza endpoints REST para dados de contas, clientes e transacções. A estrutura de API do Finacle suporta tanto consultas síncronas como notificações assíncronas de eventos de transacção por webhook.
O Oracle FlexCube (FCUBS 12+) disponibiliza uma camada de serviços RESTful através do seu Service Framework. Os serviços REST do FlexCube exigem as configurações de orquestração de serviços adequadas e suportam a autenticação OAuth 2.0 por token de portador (bearer token).
O Mambu foi concebido de raiz segundo uma lógica API-first. A Mambu Core Banking Platform expõe uma API REST abrangente, sem necessidade de configuração adicional. Os dados de transacções estão disponíveis através dos endpoints Loans, Savings e Current Account, com amplo suporte de filtragem e paginação.
Autenticação
A integração por API autentica-se através do fluxo OAuth 2.0 de credenciais de cliente (recomendado para integrações entre servidores) ou da autenticação por chave de API. A plataforma BC/FT guarda as credenciais num cofre de segredos encriptado e apresenta-as em cada pedido. Toda a comunicação por API decorre sobre HTTPS/TLS 1.2 ou superior.
Casos de utilização recomendados
A integração por API REST é o método preferencial para:
- A geração de alertas de STR em tempo real ou quase em tempo real a partir da monitorização de transacções
- A detecção do limiar de CTR transacção a transacção, face ao equivalente a 15 000 USD, com conversão cambial em tempo real
- O enriquecimento dos dados KYC (conheça o seu cliente) dos clientes (data de abertura da conta, profissão declarada, classificação de risco)
- Os dados de transacções de dinheiro móvel provenientes da API Daraja ou da API Airtel Money
Descrição da arquitectura de integração
O serviço de ingestão de dados da plataforma BC/FT mantém uma tarefa agendada que consulta a API do sistema bancário central a um intervalo configurável. O serviço autentica-se, pede as transacções posteriores ao carimbo temporal (timestamp) da última consulta bem-sucedida, mapeia os campos da resposta para o modelo interno de transacções (aplicando a normalização das datas, a formatação dos montantes, a conversão de códigos e a correspondência de entidades) e grava os registos normalizados no repositório de transacções. As chamadas à API que falham são repetidas com recuo exponencial (exponential backoff) e registadas com todo o contexto do erro, para visibilidade da equipa de operações.
Método de integração 2: transferência de ficheiros por SFTP
Como funciona
A integração por SFTP utiliza transferências agendadas de ficheiros do sistema bancário central para um servidor SFTP partilhado. O processamento em lote do sistema bancário central (normalmente configurado no âmbito do processamento de fecho do dia) gera um ficheiro de extracção de transacções num formato definido — CSV, delimitado por barras verticais (pipe) ou de largura fixa — e deposita-o num directório SFTP designado. O serviço de ingestão da plataforma BC/FT monitoriza o directório SFTP, detecta os novos ficheiros, descarrega-os e processa-os, e move-os para um directório de arquivo depois de processados com êxito.
Trata-se de um padrão consolidado e amplamente suportado, que não exige alterações ao sistema bancário central para além da configuração de um relatório de extracção e de uma tarefa SFTP. A maioria dos sistemas bancários centrais implementados na África Oriental dispõe de capacidade de exportação por SFTP na sua instalação de base.
Formatos de ficheiro suportados
O CSV (valores separados por vírgulas) é o formato mais comum nas extracções do T24 e do Finacle. Os cabeçalhos de coluna na primeira linha definem o mapeamento dos campos. A configuração de ingestão da plataforma BC/FT mapeia os nomes das colunas CSV para os campos do modelo de dados interno e aplica as regras de transformação.
Os ficheiros delimitados por barras verticais (pipe) são comuns nas exportações COB (Close of Business, fecho do dia) do T24, sobretudo nas instalações T24 mais antigas. O carácter de barra vertical (|) como delimitador evita a ambiguidade com as vírgulas que possam surgir em campos de texto, como as descrições das transacções.
Os ficheiros de largura fixa encontram-se nas instalações FlexCube mais antigas, em que cada campo ocupa um número definido de posições de carácter. O processamento de ficheiros de largura fixa exige uma especificação da disposição dos campos (que posições de carácter correspondem a que campo), documentada na configuração de extracção do sistema bancário central.
Periodicidade e calendário
A integração por SFTP funciona, por natureza, em lotes. A periodicidade padrão é uma extracção no fecho do dia que abrange todas as transacções desde a extracção anterior. Para a monitorização do limiar das CTR, o processamento em lote no fecho do dia é viável, mas apertado: como o prazo de submissão termina na sexta-feira da semana, uma transacção de segunda-feira tem de ser detectada, revista, aprovada e submetida em quatro dias úteis, e uma transacção de quinta-feira num só dia. O SFTP no fecho do dia é aceitável para instituições com fluxos de trabalho de conformidade maduros, mas várias extracções intradiárias — ou a passagem para a ingestão por API — reduzem significativamente o risco de incumprimento dos prazos.
Para as instituições que necessitam de detectar os limiares ao longo do dia (para identificar as transacções em numerário iguais ou superiores ao equivalente a 15 000 USD logo que são lançadas), pode ser configurada uma extracção intradiária adicional, normalmente ao meio-dia. Alguns sistemas bancários centrais suportam extracções desencadeadas a intervalos intradiários configuráveis.
O método mais popular para o T24 e o Finacle
A extracção por SFTP é, de longe, o método de integração mais implementado na banca da África Oriental. As suas vantagens são a simplicidade, a universalidade (todos os sistemas bancários centrais a suportam), a total independência face à disponibilidade da camada de API do sistema bancário central e a maturidade das ferramentas disponíveis para a monitorização e o processamento de SFTP.
As instituições que não têm acesso imediato a recursos para configurar o T24 API Server, ou cujo Finacle Connect Gateway ainda não está licenciado, podem implementar a integração por SFTP com uma configuração de relatório padrão e uma credencial SFTP — tarefas ao alcance da maioria das equipas de operações de TI, sem recursos de desenvolvimento especializados.
Segurança: protocolo SFTP, autenticação por chave, ficheiros encriptados
O SFTP (SSH File Transfer Protocol) proporciona uma encriptação forte na camada de transporte, ao contrário do FTP legado, que transmite os dados em texto simples. A autenticação por chaves SSH elimina os riscos de segurança associados às palavras-passe. Os ficheiros de extracção de transacções que contenham dados de clientes devem ser adicionalmente encriptados em repouso, com encriptação PGP ou AES-256, antes de serem depositados no servidor SFTP, e desencriptados pela plataforma BC/FT após a descarga. Esta segurança em camadas garante que, mesmo que as credenciais SFTP sejam comprometidas, os ficheiros de dados de transacções não podem ser lidos sem a chave de desencriptação.
Método de integração 3: importação CSV/Excel
Caso de utilização
A importação manual de CSV/Excel é disponibilizada como método de integração alternativo para as instituições que não dispõem da infra-estrutura ou dos recursos de TI necessários a uma integração automatizada por API ou SFTP. É particularmente relevante para as SACCO (cooperativas de poupança e crédito) mais pequenas, as instituições de microfinanças de nível 3 e os bancos comunitários que possam não ter pessoal dedicado às operações de TI.
O responsável pela conformidade (ou um elemento designado da equipa de TI) exporta um relatório de transacções do sistema bancário central, descarrega-o em formato CSV ou Excel e carrega-o na plataforma BC/FT através da interface de importação. A plataforma valida a estrutura do ficheiro, mapeia as colunas para o modelo de dados, assinala os problemas de qualidade dos dados para revisão e carrega as transacções no fluxo de trabalho de conformidade.
Formato do modelo padrão
A plataforma BC/FT disponibiliza um modelo de importação em formato Excel, que pode ser descarregado e que predefine a estrutura de colunas exigida, os formatos de dados aceitáveis para cada campo e as regras de validação. As instituições que utilizam exportações CSV personalizadas do seu sistema bancário central recorrem à configuração de mapeamento de colunas para definir que coluna da sua exportação corresponde a que campo do modelo. Este mapeamento é configurado uma única vez e guardado, pelo que as importações seguintes exigem apenas o carregamento do ficheiro.
Validação dos dados na importação
A cadeia de importação aplica as mesmas validações de qualidade dos dados que as cadeias de ingestão automatizadas:
- Validação e normalização do formato das datas
- Validação do formato dos montantes (numérico, duas casas decimais)
- Detecção de transacções duplicadas (as transacções que já constam do sistema são assinaladas e ignoradas)
- Verificação da presença dos campos obrigatórios
- Validação do formato dos números de conta
- Verificação dos campos de identificação do cliente
Os erros de validação são apresentados num relatório de síntese que o operador revê antes de confirmar a importação. Os registos com erros não críticos podem ser importados com sinalizações para revisão manual; os registos com erros críticos são excluídos e têm de ser corrigidos nos dados de origem e carregados de novo.
Limitações
A importação manual de CSV/Excel tem duas limitações significativas em comparação com a integração automatizada:
Em primeiro lugar, é desencadeada manualmente. Um responsável pela conformidade tem de se lembrar de fazer a importação na periodicidade correcta. As importações esquecidas criam lacunas nos dados de transacções que alimentam a monitorização dos limiares e a pontuação de risco, o que pode resultar em CTR não submetidas.
Em segundo lugar, o trilho de auditoria da origem dos dados é menos completo. As integrações automatizadas registam, para cada registo ingerido, o sistema de origem exacto, a data e hora da exportação e o método de transferência. As importações manuais registam apenas o nome do ficheiro, a data e hora do carregamento e o utilizador que o carregou — informação que pode ser insuficiente para rastrear a proveniência dos dados numa investigação.
Por estas razões, a importação CSV/Excel deve ser tratada como um método transitório enquanto a integração automatizada é implementada, e não como uma arquitectura de integração permanente para instituições com obrigações de comunicação significativas.
Integração dos dados de dinheiro móvel
API Daraja do M-PESA
A API Daraja do M-PESA (a plataforma de API para programadores da Safaricom) dá acesso aos dados de transacções M-PESA às empresas registadas. Para os bancos com integrações M-PESA Pay Bill ou Buy Goods, a API C2B (Customer to Business) da Daraja entrega notificações de transacções em tempo real, sob a forma de chamadas de retorno (callbacks) HTTP, quando um cliente efectua um pagamento.
Para efeitos de monitorização dos limiares BC/FT, os endpoints Daraja relevantes são:
- C2B API: recebe notificações em tempo real dos pagamentos M-PESA para o número Pay Bill do banco
- Account Balance API: consulta o saldo actual da conta de um código curto (short code) Pay Bill específico
- Transaction Status API: consulta o estado de uma transacção M-PESA específica através do seu identificador único de transacção
A API Daraja utiliza a autenticação OAuth 2.0 com chave e segredo de consumidor (consumer key/secret). A plataforma BC/FT regista-se como URL de retorno (callback) C2B para receber as notificações de pagamento em tempo real, normaliza os dados das transacções M-PESA (MSISDN, montante, identificador da transacção, data e hora, referência da conta) para o modelo interno de transacções e inclui-os na mesma cadeia de monitorização dos limiares que as transacções de balcão e de ATM.
API Airtel Money
A API da Airtel Money oferece funcionalidades semelhantes às da Daraja do M-PESA para os bancos com integrações de comerciante Airtel Money. O modelo de autenticação e o padrão de chamadas de retorno são comparáveis, com convenções de nomenclatura de campos próprias da Airtel que exigem mapeamento para o modelo de dados normalizado da plataforma BC/FT.
T-Kash (Telkom Kenya)
O T-Kash disponibiliza acesso por API a programadores para integrações empresariais, embora a sua quota de mercado seja significativamente menor do que a do M-PESA. Os bancos com contas de comerciante T-Kash podem integrar os dados de transacções T-Kash através da sua camada de API empresarial.
Monitorização transversal a todos os canais para a detecção de CTR e STR
O requisito crítico da integração do dinheiro móvel é que as transacções M-PESA sejam avaliadas na mesma cadeia de detecção que as transacções em numerário ao balcão, os levantamentos em ATM e todos os outros canais que movimentam fundos de clientes. As transacções em numerário ao balcão e em ATM são testadas individualmente face ao limiar de CTR equivalente a 15 000 USD; para o dinheiro móvel, aplique o tratamento que tiver confirmado com o Financial Reporting Centre (FRC), a UIF do Quénia, porque nem a POCAMLA, nem os Regulamentos de 2023, nem a Circular n.º 4 de 2023 do FRC o regulam. Em paralelo, a actividade abaixo do limiar em todos os canais alimenta a vigilância de padrões de fraccionamento que dá origem aos casos de STR. Ambas as vias exigem uma camada unificada de identidade do cliente, que ligue o MSISDN M-PESA do cliente ao seu identificador de cliente e ao seu número de conta no sistema bancário central.
A correspondência de identidades é o elemento tecnicamente mais exigente: a conta M-PESA de um cliente é identificada pelo seu número de telemóvel, enquanto a sua conta no sistema bancário central é identificada por um número de conta e um identificador de cliente. A plataforma BC/FT mantém uma tabela de correspondência de clientes que associa os MSISDN aos identificadores de cliente, preenchida a partir dos registos KYC do banco. Esta tabela de correspondência permite uma resolução coerente da identidade do cliente em todos os canais de transacção.
Mapeamento de dados — dos campos do sistema bancário central para o esquema goAML
A tabela seguinte mostra o mapeamento dos campos da extracção de transacções padrão do Temenos T24 para os elementos XML goAML, incluindo a transformação necessária para cada campo.
| Campo do sistema bancário central (T24) | Elemento XML goAML | Transformação necessária |
|---|---|---|
| TRANS.DATE (formato: YYYY-MM-DD) | transaction.date_transaction | Nenhuma — já em ISO 8601 |
| TRANS.AMT (cadeia de caracteres, pode incluir vírgulas) | currency_amount.amount | Remover as vírgulas, converter para decimal, formatar com 2 casas decimais |
| TRANS.CCY (código ISO de 3 caracteres) | currency_amount.currency_code | Nenhuma |
| DEBIT.ACCT.NO | from_account.account.account_number | Remover os zeros à esquerda, se existirem |
| CREDIT.ACCT.NO | to_account.account.account_number | Remover os zeros à esquerda, se existirem |
| TRANS.CODE (numérico, p. ex. 01) | transaction.transaction_type | Mapear através de uma tabela de códigos para a enumeração goAML |
| CUSTOMER.1 (nome completo do cliente) | from_person.first_name + last_name | Separar em nome próprio e apelido com uma lógica de divisão do nome |
| ID.DOCUMENT (número do National ID) | id_number | Validar o formato (8 dígitos para o National ID queniano) |
| CHANNEL.CODE | transaction_type | Mapear para MOBILE_WALLET_MPESA, CASH, etc. |
| BRANCH.CODE | transaction_location | Mapear para o nome do balcão a partir do registo de balcões |
Sem alterações ao seu sistema bancário central
Uma preocupação que surge com frequência nas discussões sobre a integração BC/FT é a eventual modificação do sistema bancário central. Os bancos são, com razão, cautelosos em relação a qualquer alteração ao seu sistema bancário central — é o sistema mais crítico da instituição, as alterações exigem testes exaustivos e pode ser necessária a aprovação do fornecedor.
A integração da plataforma BC/FT foi concebida para funcionar exclusivamente em modo de leitura. A plataforma BC/FT consulta os dados de transacções, mas nunca escreve no sistema bancário central. Não são necessários procedimentos armazenados, triggers nem alterações de esquema na base de dados do sistema bancário central. Não são instalados agentes nem processos em segundo plano nos servidores do sistema bancário central. A integração é um fluxo de dados unidireccional: do sistema bancário central para a plataforma BC/FT.
Na integração por API, o API Server do sistema bancário central é um componente separado da própria aplicação bancária central — chamar a API não modifica nem põe em risco essa aplicação. Na integração por SFTP, o sistema bancário central produz um ficheiro de relatório no âmbito do seu processamento em lote já existente — trata-se de uma capacidade de reporte padrão, que acrescenta uma carga insignificante.
Abordagem independente do fornecedor
A camada de ingestão da plataforma BC/FT foi concebida para se adaptar ao formato e à estrutura de dados específicos de qualquer sistema bancário central, sem exigir o envolvimento do fornecedor desse sistema. A integração é configurada pela equipa de TI do banco através de definições de mapeamento de campos e de regras de transformação mantidas na configuração da plataforma BC/FT — e não no sistema bancário central.
Esta abordagem independente do fornecedor significa que, se o banco mudar de sistema bancário central, a configuração da integração é actualizada na plataforma BC/FT, e não reconstruída de raiz. A função de conformidade mantém-se operacional durante as migrações do sistema bancário central.
Calendário de implementação
A integração com o sistema bancário central fica normalmente concluída em 1 a 2 semanas, no âmbito de uma implementação padrão da plataforma BC/FT de 6 a 8 semanas. A fase de configuração da integração exige a participação da equipa de TI responsável pelo sistema bancário central (para confirmar os nomes dos campos, os formatos e as modalidades de acesso SFTP ou API) e fica normalmente concluída poucos dias após o arranque do projecto. O restante tempo de implementação abrange os testes, a validação da qualidade dos dados, a formação da equipa de conformidade e a configuração do portal da UIF.
Dê o passo seguinte
A plataforma de comunicações goAML da Creodata inclui uma camada de ingestão de dados flexível que suporta API REST, SFTP e importação CSV/Excel para todos os principais sistemas bancários centrais da África Oriental. A nossa equipa de integração já concluiu integrações com o Temenos T24, o Infosys Finacle, o Oracle FlexCube, o Mambu e várias configurações M-PESA e Airtel Money — com bibliotecas documentadas de mapeamento de campos para cada um deles.
Discuta com a nossa equipa os requisitos de integração do seu sistema bancário central: Pedir uma demonstração em creodata.com/demo
