Conetividade bancária, de tesouraria e ISO 20022
Pagamentos enviados, extratos recebidos, reconciliados automaticamente em todas as moedas
As equipas de tesouraria ainda redigitam pagamentos e reconciliam extratos à mão
Muitas equipas de tesouraria introduzem pagamentos em portais bancários, recebem extratos em formatos diferentes de cada banco e reconciliam contas em folhas de cálculo no fecho do mês. Cada etapa manual é um atraso, um custo e uma chance de fraude ou erro.
Os bancos também estão a migrar para o ISO 20022, o padrão internacional para mensagens financeiras, que carrega dados estruturados mais ricos do que os antigos formatos SWIFT MT. Sistemas que não conseguem produzi-lo nem lê-lo ficam para trás em relação aos seus bancos.
O que muda para si
Processamento direto
Lotes de pagamento aprovados saem do ERP como ficheiros assinados ou chamadas de API, e os extratos voltam num formato que o ERP reconcilia sozinho.
Um fecho mais rápido
Reconciliação em várias moedas que corre todos os dias, em vez de envios manuais de CSV e ajustes de folha de cálculo no fim do mês.
Cada exceção com uma pessoa
Pagamentos rejeitados e linhas não reconciliadas chegam a uma fila de exceções de mensagens não entregues com o motivo, nunca se perdem numa caixa de correio.
O que entregamos
Host-to-host e conetividade bancária direta
Ligações por SFTP, EBICS e SWIFT, e APIs de open banking e bancárias diretas, escolhidas por banco e por país.
Geração de ficheiros de pagamento
Ficheiros de pagamento ISO 20022 pain.001 gerados a partir dos seus lotes de pagamento, validados contra a variante de cada banco e assinados ou encriptados conforme ele exigir.
Tratamento de estado e rejeições
Relatórios de estado pain.002 recolhidos, para que cada pagamento apareça como aceite, rejeitado ou pendente, com o código de motivo do banco.
Ingestão de extratos
Extratos de fim de dia camt.053 e MT940 e relatórios intradiários recolhidos, verificados quanto a lacunas e duplicidades e carregados no ERP.
Mensageria interbancária para bancos e fintechs
Mensagens pacs para transferências de crédito e o seu estado entre instituições financeiras, ligadas aos razões do core banking.
Reconciliação em várias moedas
Regras de correspondência que liquidam itens abertos automaticamente entre moedas e contas e enviam o restante para uma fila de exceções.
Evidências de testes bancários e manuais de operação
Os casos de teste de cada banco executados e registados para os seus auditores, e alertas de ficheiros ausentes, transferências com falha e chaves ou certificados a expirar.
Como trabalhamos
Mapear bancos e fluxos
Listamos os seus bancos, contas, tipos de pagamento e etapas manuais atuais, e acordamos quais fluxos vêm primeiro.
Especificar cada formato
Trabalhamos a partir do guia de implementação de cada banco e escrevemos o mapeamento, incluindo assinatura, criptografia e nomenclatura de ficheiros.
Construir os conectores
Construímos exportação de pagamentos, importação de estado, importação de extratos e reconciliação, com testes automatizados para cada formato.
Testar com cada banco
Executamos os casos de teste acordados no ambiente de teste do banco e corrigimos o que a validação do banco rejeitar.
Entrar em produção banco a banco
Trocamos um banco de cada vez, com o processo atual pronto como alternativa até o novo ser comprovado.
Monitorizar e dar suporte
Acompanhamos transferências, chaves e expiração de certificados, e planeamos as mudanças de formato conforme os bancos as anunciam.
Role para o lado para ver o desenho completo.
ERP para banco: pagamentos saem, extratos entram
Pagamentos aprovados saem do ERP como ficheiros ISO 20022 assinados por um canal host-to-host. Relatórios de estado e extratos voltam pelo mesmo caminho e são reconciliados com os itens abertos. Rejeições e linhas não reconciliadas vão para a sua equipa com o motivo anexado.
- Fluxo principal
- Assíncrono
- Caminho de exceção
O fluxo em 10 etapas
O fluxo, etapa a etapa
- De ERP para Camada de integração: Lote de pagamentos aprovado, por REST/JSON · IDoc (fluxo principal).
- De Camada de integração para Canal bancário seguro: Ficheiro de pagamento assinado e encriptado, por ISO 20022 pain.001 · OpenPGP (fluxo principal).
- De Canal bancário seguro para Banco: Entregue ao banco, por SFTP H2H (fluxo principal).
- De Banco para Canal bancário seguro: Relatórios de estado e extratos, por pain.002 · camt.053 · MT940 (assíncrono).
- De Canal bancário seguro para Camada de integração: Recolhidos e validados, por SFTP H2H (assíncrono).
- De Camada de integração para Motor de reconciliação: Linhas do extrato, por camt.053 (assíncrono).
- De Motor de reconciliação para ERP: Lançamentos reconciliados registados, por REST/JSON (fluxo principal).
- De Camada de integração para Equipa de tesouraria e finanças: Pagamentos rejeitados, com o código de motivo, por pain.002 RJCT (caminho de exceção).
- De Motor de reconciliação para Equipa de tesouraria e finanças: Linhas não reconciliadas: uma divergência de reconciliação (caminho de exceção).
- De Equipa de tesouraria e finanças para ERP: Corrigidos e reenviados (caminho de exceção).
Role para o lado para ver o desenho completo.
Open banking: dados e pagamentos com o consentimento do cliente
O cliente concede consentimento, o conector guarda os tokens, e cada chamada ao banco é autorizada e registada. Quando o consentimento expira ou é retirado, a aplicação pede novamente ao cliente em vez de falhar em silêncio.
- Fluxo principal
- Assíncrono
- Caminho de exceção
O fluxo em 7 etapas
O fluxo, etapa a etapa
- De Cliente para A sua aplicação ou plataforma: Concede consentimento (fluxo principal).
- De A sua aplicação ou plataforma para Conector de open banking: Pedidos de conta e de pagamento, por REST/JSON (fluxo principal).
- De Conector de open banking para APIs bancárias ou agregador: Chamadas de API autorizadas, por OAuth 2.0 · FAPI · REST (fluxo principal).
- De APIs bancárias ou agregador para Conector de open banking: Saldos, transações e estado de pagamento, por REST/JSON · webhook (assíncrono).
- De Conector de open banking para ERP ou razão: Transações normalizadas, por REST/JSON (fluxo principal).
- De APIs bancárias ou agregador para Conector de open banking: Consentimento expirado ou retirado, por HTTP 401 · 403 (caminho de exceção).
- De Conector de open banking para A sua aplicação ou plataforma: Pedido ao cliente que renove o consentimento (caminho de exceção).
Padrões, formatos e canais
Construímos a partir do guia de implementação de cada banco, não apenas do padrão. Nomear um produto não significa uma parceria com o fornecedor.
- Normas e canais bancários
- ISO 20022
- pain.001
- pain.002
- camt.052
- camt.053
- camt.054
- MT940
- MT942
- Swift
- EBICS
- SFTP (H2H)
- OpenPGP
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
Prova em produção
Para um banco de grande porte do Golfo e um conglomerado regional, ligamos o SAP S/4HANA às infraestruturas bancárias regionais por ISO 20022. Os pagamentos são assinados, as exceções chegam a filas de mensagens não entregues e a reconciliação entre as suas contas bancárias é automática.
Como começar
Requisitos claros de bancos e formatos vão direto para uma proposta. Vários bancos, países ou uma interface legada não documentada normalmente começam pelo Blueprint Studio ou pela Ponte de Diagnóstico Brownfield.
O que acontece a seguir
Sessão de pré-consultoria
Uma sessão em linha gratuita de pré-consultoria de 30 minutos: analisamos os seus objetivos, sistemas e restrições.
Avaliação de prontidão
Numa avaliação de prontidão gratuita de 48 horas, um Arquiteto Principal verifica o seu projeto com a Definição de Prontidão em 6 pontos e recomenda o percurso adequado.
Escolha do percurso
Projetos com âmbito pronto recebem uma proposta vinculante em 3–5 dias úteis. Projetos em estágio de conceito começam no Blueprint Studio. Um sistema em produção com falhas, não documentado ou que precisa de integração começa com um diagnóstico de 1–2 semanas. O Blueprint Studio e o diagnóstico têm cada um uma taxa fixa, cotada na proposta.
Entrega em cinco etapas
Mobilização, sprints com demonstrações ao vivo, integração e robustecimento, aceitação e entrada em produção e, depois, serviços geridos. Após o lançamento vem um período de garantia e, depois, suporte e manutenção opcionais.
Projetos com resultado fixo e serviços geridos 24/7
Entrega com âmbito fixo e orientada a marcos, com responsáveis de entrega nomeados, e serviços geridos de aplicação 24 horas por dia sob governação de SLA.
Especialistas embarcados e reforço estratégico
Engenheiros principais e especialistas nearshore e no local, e arquitetos embarcados de solução, de transformação, de PQC e de integração.
Perguntas e respostas
O que é o ISO 20022 e por que é importante?
O ISO 20022 é o padrão internacional para mensagens financeiras. As suas mensagens XML carregam dados estruturados, como nomes completos, endereços e dados de remessa, que os antigos formatos SWIFT MT não conseguem. Bancos e sistemas de pagamento migraram para ele, por isso ficheiros de pagamento e de extrato construídos sobre ele reconciliam melhor e passam por verificações de conformidade com mais frequência.
Com quais formatos e canais bancários trabalham?
Usamos pain.001 para pagamentos, pain.002 para estado, camt.052, camt.053 e camt.054 para relatórios de conta e mensagens pacs entre bancos. Também lemos os extratos MT940 e MT942 que muitos bancos ainda enviam. O transporte é host-to-host por SFTP, EBICS, SWIFT ou APIs bancárias. Cada banco tem a sua própria variante de cada formato, por isso construímos a partir do guia de implementação dele.
A quais bancos conseguem ligar os sistemas ERP?
SAP S/4HANA, Oracle Fusion Cloud ERP e NetSuite, Microsoft Dynamics 365, Odoo e Sage, além de sistemas de tesouraria e sistemas à medida. Quando o ERP tem o seu próprio módulo de comunicação bancária, configuramos e ampliamos esse módulo em vez de construir por fora.
Como mantêm os ficheiros de pagamento seguros?
Os ficheiros de pagamento são assinados e encriptados conforme cada banco exige e circulam apenas pelo canal acordado. Chaves e certificados ficam no seu cofre de chaves ou módulo de segurança de hardware, nunca no código. Os ficheiros são validados antes do envio, e cada transferência é registada, para que possa seguir quem aprovou e enviou cada pagamento.
O que acontece quando uma linha de extrato não corresponde?
Ela vai para uma lista de revisão com os candidatos prováveis e o motivo de não ter correspondido, como um valor diferente ou uma referência ausente. A sua equipa a resolve ali, e as regras podem ser ajustadas para que o mesmo caso corresponda na próxima vez. Nada é lançado no razão sem uma correspondência aprovada por si.
O que determina o ritmo de uma integração bancária?
Principalmente o banco, não o código. Cada banco define as suas próprias etapas de integração, janelas de teste e aprovações, e alguns exigem contratos ou troca de chaves antes de os testes começarem. Após a etapa de mapeamento, entregamos um plano por banco e começamos a testar com o banco que estiver pronto primeiro.
O que acontece quando um banco muda o seu formato?
Os bancos anunciam mudanças de formato com antecedência, como muitos fizeram ao migrar do SWIFT MT para o ISO 20022. Acompanhamos esses avisos para os bancos que ligamos, avaliamos o impacto e agendamos a mudança e os seus testes com o banco antes do prazo dele.
Pronto para construir? Peça uma proposta.
Envie os seus requisitos ou o seu RFP. Os nossos arquitetos os validam e devolvem uma proposta vinculante de âmbito fixo.
O que acontece a seguir
Avaliação de prontidão
Numa avaliação de prontidão gratuita de 48 horas, um Arquiteto Principal verifica o seu projeto com a Definição de Prontidão em 6 pontos e recomenda o percurso adequado.
Proposta vinculante
Após validação de arquitetura sem custo, recebe uma proposta vinculante de âmbito fixo em 3–5 dias úteis: marcos, arquitetura, estrutura da equipa e SLAs. Assinamos um acordo de confidencialidade (NDA) consigo quando solicitado, antes de partilhar os seus requisitos.
Mobilização
Depois da assinatura, as nossas equipas de engenharia iniciam o Sprint 0 em 5–10 dias úteis após a assinatura do contrato.
Entrega em cinco etapas
Mobilização, sprints com demonstrações ao vivo, integração e robustecimento, aceitação e entrada em produção e, depois, serviços geridos. Após o lançamento vem um período de garantia e, depois, suporte e manutenção opcionais.