Transferências IP/IP e IPZip

IP to IP (IPIP)

As transferências IP para IP referem-se a uma parte do processo de transferência de moeda ou de ativos, passivos e capitais próprios, a partir de contas de bancos correspondentes ou de dados entre diferentes instituições ou sistemas financeiros, mediante a utilização de endereços de Protocolo de Internet (IP). No contexto das transações financeiras, o endereço IP é um identificador numérico único atribuído a cada dispositivo ligado à internet e é utilizado para encaminhar informação entre diferentes sistemas. As transferências IP para IP no setor bancário implicam a comunicação direta entre dois sistemas, através dos respetivos endereços IP, para facilitar uma transação financeira. São utilizados métodos especiais de autenticação e autorização adicionais para garantir a integridade e a segurança da informação.

Importa, contudo, salientar que as transferências de IP para IP não são comuns nem recomendadas no setor bancário, por diversas razões, nomeadamente preocupações de segurança, fiabilidade e conformidade. Os pontos seguintes enquadram estas preocupações:

1. Segurança: As transferências de IP para IP podem ser menos seguras do que as redes bancárias consolidadas, como a SWIFT ou a ACH, que aplicam múltiplas camadas de segurança, cifragem e autenticação. A comunicação direta entre dois endereços IP pode expor informações sensíveis a potenciais ameaças de segurança, incluindo ataques informáticos, phishing ou ataques man-in-the-middle.
2. Fiabilidade: A utilização de transferências de IP para IP não garante a fiabilidade da transação, uma vez que não existem normas ou protocolos universalmente reconhecidos para transferências baseadas em IP no setor bancário. Tal pode originar problemas no processamento, no acompanhamento e na reconciliação das transações.
3. Conformidade: Os bancos e as instituições financeiras estão sujeitos a numerosas regulamentações e exigências, incluindo as políticas de Prevenção do Branqueamento de Capitais (AML) e Conheça o Seu Cliente (KYC). As transferências de IP para IP podem não cumprir estes requisitos regulamentares, expondo potencialmente as partes envolvidas a riscos jurídicos e financeiros.

Em vez de transferências de IP para IP, os bancos e as instituições financeiras preferem utilizar redes estabelecidas, como a SWIFT, o RTGS ou os sistemas ACH/Pagamentos Imediatos, e normas de mensagens como a ISO 20022, para facilitar transferências de fundos seguras, fiáveis e conformes entre diferentes instituições.

Principais Diferenças entre Servidores de Comunicações e Servidores de Registo/Contas nos Bancos

Na tecnologia bancária, os servidores desempenham um papel determinante para assegurar o bom funcionamento das transações financeiras e dos registos contabilísticos. Os dois principais tipos de servidores em que os bancos se apoiam são os servidores de comunicação e os servidores de livro-razão/contas. Embora ambos sejam essenciais, servem finalidades distintas e tratam diferentes tipos de dados.

Servidores de Comunicações

Os servidores de comunicação constituem a espinha dorsal da troca segura de dados entre bancos e instituições financeiras. Seguem-se as principais funções e características dos servidores de comunicação:

1. Troca Segura de Dados: Estes servidores facilitam a troca segura de dados, assegurando que a informação financeira sensível pode ser transmitida entre instituições sem comprometer a sua segurança.
2. Protocolos e normas: Utilizam protocolos normalizados, como SWIFT, SEPA ou ACH, entre outros, para a comunicação interbancária, assegurando uniformidade e fiabilidade entre diferentes plataformas.
3. Cifragem e Autenticação: Para preservar a segurança, os servidores de comunicação recorrem a métodos de cifragem avançados e a protocolos de autenticação rigorosos, protegendo os dados durante a transmissão.
4. Tratamento de Transações: Essencialmente, tratam os pedidos, as mensagens e as instruções relativos a transações, atuando como intermediários que transmitem a informação necessária para a sua execução.
5. Ausência de Movimentação de Fundos: É importante salientar que estes servidores não movimentam fundos nem atualizam diretamente os saldos das contas; limitam-se a facilitar a comunicação necessária para essas ações.

Servidores de Registos/Contas

Os servidores de contabilidade/contas, por seu turno, são os depositários dos registos financeiros de um banco. Seguem-se as suas principais características:

1. Manutenção de Registos Financeiros: Estes servidores armazenam e mantêm os registos financeiros essenciais do banco, assegurando que cada transação é registada com rigor.
2. Registo de Transações: Registam todas as transações, incluindo débitos e créditos, e são responsáveis pela atualização e conservação dos saldos correntes das contas.
3. Gestão do Razão Geral: os servidores de razão gerem o razão geral do banco, bem como as contas individuais dos clientes, proporcionando uma visão completa da situação financeira.
4. Integridade dos Dados: Assegurar a consistência e a integridade dos dados é essencial, uma vez que estes registos são indispensáveis para a prestação de informação financeira rigorosa e para a conformidade.
5. Medidas de Segurança Reforçadas: dada a sensibilidade dos dados, os servidores de registo (ledger) adotam, em regra, medidas de segurança mais rigorosas, incluindo camadas adicionais de encriptação e controlos de acesso estritos.

O servidor de comunicações inicia e facilita as transações, mas é o servidor de registos contabilísticos que, em última análise, as regista e reflete, após validação, nos livros do banco.

Nos sistemas bancários contemporâneos, estas funções encontram-se frequentemente integradas, funcionando os protocolos seguros de comunicação interna do banco em articulação com os sistemas de gestão de livros contabilísticos. Esta integração assegura atualizações em tempo real e coerência em todo o ecossistema financeiro do banco, reforçando simultaneamente a eficiência e a segurança. Muitos bancos recorrem a uma combinação de servidores locais e em nuvem para equilibrar os requisitos de segurança, de conformidade e de escalabilidade.

Transferência efetiva de ativos, passivos e capitais próprios: As transferências de valores mobiliários são registadas pelas centrais de valores mobiliários (CSD), que mantêm o registo jurídico da titularidade; os empréstimos, os ativos fixos e outras posições são transmitidos mediante acordos de cessão ou de transferência, ao abrigo da lei aplicável. Ambos os aspetos ficam fora do âmbito dos protocolos de comunicação. A transferência de ativos e de capitais próprios afeta também as demonstrações financeiras dos bancos, alterando os saldos do passivo, do ativo e dos capitais próprios. A prestação de informação financeira às autoridades de controlo competentes e o necessário cumprimento das exigências de Conformidade excedem as capacidades de transmissão de dados dos protocolos e requerem processos financeiros e regulamentares adicionais.

Em suma, embora os protocolos sejam essenciais para a troca segura e eficiente de informação nas transações IPIP, o processo completo envolve sistemas adicionais para a efetiva movimentação de moeda, ativos, passivos e capitais próprios, para a liquidação, o registo jurídico e o reporte financeiro, assegurando que toda a transação é executada em conformidade com as normas bancárias regulamentares.

Transferência IP ZIP

Transmissão Segura Baseada em Ficheiros de Instruções de Pagamento Institucionais

Uma Transferência IP ZIP compreende-se melhor como um método seguro, baseado em ficheiros, para a transmissão de instruções de pagamento estruturadas e dos dados de transação associados, diretamente entre sistemas institucionais autenticados, através de uma rede de Protocolo de Internet.

A terminologia exige particular precisão.

Uma transmissão IP ZIP não é um sistema de compensação, um sistema de liquidação, uma infraestrutura de pagamento nem um mecanismo autónomo de transferência de valor monetário. O arquivo ZIP é um contentor de transporte. A ligação IP é o canal de comunicação. A informação contida no arquivo constitui uma instrução, um conjunto de dados ou uma mensagem de transação.

Em conformidade:

O IP ZIP transmite informação e instruções de pagamento. Por si só, não liquida fundos.

Em termos conceptuais, é comparável à distinção aplicável a uma mensagem ISO 20022 pacs.008 (Transferência a Crédito de Cliente entre Instituições Financeiras). Uma mensagem pacs.008 pode veicular uma instrução de transferência a crédito interbancária altamente estruturada, mas a própria mensagem não deve ser confundida com a movimentação e liquidação efetivas de moeda de banco central, moeda de bancos comerciais ou saldos de contas de correspondentes.

O mesmo princípio aplica-se a uma transmissão ZIP por IP.

2. O Ficheiro ZIP como Contentor Seguro de Transações

O componente ZIP serve principalmente como mecanismo de acondicionamento e empacotamento.

Em vez de transmitir separadamente cada um dos componentes da transação, a instituição ordenante pode reunir os ficheiros relevantes num único pacote controlado.

Consoante a especificação bilateral acordada, tal pacote pode conter:

• instruções de pagamento estruturadas;
• Mensagens de pagamento em XML;
• conjuntos de dados compatíveis com ISO 20022;
• objetos de transação JSON;
• Registos de transações em formato CSV ou de formato fixo;
• ficheiros de pagamentos interbancários proprietários;
• informação sobre o devedor e o credor;
• informações sobre a conta de origem e a conta do beneficiário;
• identificadores de transações;
• informação sobre a moeda e o montante;
• datas de execução e de valor solicitadas;
• instruções dos bancos correspondentes;
• informações sobre o banco intermediário;
• informação de remessa;
• informações de encaminhamento de liquidação;
• documentação de conformidade;
• Referências de KYC ou KYB;
• informações sobre a origem dos fundos;
• manifestos de transações;
• assinaturas digitais;
• funções de dispersão criptográficas (hashes);
• certificados;
• registos de data e hora;
• ficheiros de reconciliação; e
• totais de controlo.

O arquivo pode, assim, conter tanto a instrução de pagamento principal como as informações acessórias necessárias para autenticar, validar, processar e reconciliar essa instrução.

A compressão é tecnicamente incidental. O objetivo principal é o empacotamento e a transmissão controlados.

Um arquivo ZIP nunca deve, por conseguinte, ser tratado como prova de que os fundos nele representados existem, estão disponíveis, estão livres de ónus ou foram liquidados.

3. Instrução de Pagamento Estruturada

Quando adequadamente concebida, a instrução de pagamento contida num pacote IP ZIP pode desempenhar uma função análoga à de uma mensagem financeira estruturada convencional.

Por exemplo, uma instituição poderá transmitir uma instrução XML que contenha campos correspondentes à informação normalmente constante de uma mensagem pacs.008 da norma ISO 20022, incluindo:

• identificação da mensagem;
• data e hora de criação;
• número de transações;
• informação de liquidação;
• agente instrutor;
• agente instruído;
• devedor;
• conta do devedor;
• agente do devedor;
• agente do credor;
• credor;
• conta do credor;
• montante ordenado;
• moeda;
• responsável pelos encargos;
• identificação do pagamento;
• identificação ponta a ponta; e
• informação de pagamento.

A distinção crucial é que a estrutura de dados não determina o mecanismo de liquidação.

Uma instrução de pagamento tecnicamente válida pode ser recebida, autenticada e aceite pelo sistema recetor sem que a correspondente liquidação financeira esteja concluída.

Assim:

Instrução recebida ≠ fundos recebidos

Instrução autenticada ≠ fundos liquidados

Ficheiro importado com êxito ≠ beneficiário creditado com fundos definitivos

Aviso de receção do servidor ≠ confirmação de liquidação

Esta distinção é fundamental para o tratamento que o IFB dá às metodologias alternativas de transferência.

4. Protocolos de Transmissão

As transmissões institucionais de IP ZIP devem realizar-se exclusivamente num ambiente de comunicações controlado e autenticado.

Consoante o acordo técnico bilateral, a transmissão pode recorrer a tecnologias como:

SFTP

O Secure File Transfer Protocol over SSH assegura transporte cifrado, autenticação do servidor e autenticação controlada dos utilizadores.

A autenticação por chave pública deve, em regra, ser preferida à autenticação apenas por palavra-passe na conectividade institucional.

FTPS

O FTP pode ser protegido através de TLS sempre que a infraestrutura legada o exija, desde que sejam aplicados mecanismos adequados de validação de certificados, normas de cifragem e controlos de acesso.

HTTPS / API REST

O pacote pode ser transmitido através de um ponto de acesso HTTPS autenticado ou de uma arquitetura de API que utilize TLS e autenticação adequada ao nível da aplicação.

TLS mútuo

Para ligações institucionais com maior nível de garantia, o TLS mútuo (mTLS) permite que ambos os pontos de ligação se autentiquem reciprocamente através de certificados digitais.

Isto proporciona uma proteção materialmente mais forte contra terminais não autorizados do que a autenticação unilateral do servidor, por si só.

VPN

Pode estabelecer-se uma VPN IPSec site-to-site, ou equivalente, que crie um túnel privado cifrado entre as instituições participantes antes de ocorrer a transmissão ao nível da aplicação.

Conectividade Privada Dedicada

Sempre que os volumes de transações, os requisitos de segurança ou os perfis de risco institucionais o justifiquem, a conectividade dedicada ou por rede privada pode complementar ou substituir a transmissão através da Internet pública.

O protocolo exato tem de ser acordado bilateralmente antes da ativação operacional.

5. Autenticação de Terminais

A instituição recetora deve certificar-se de que a transmissão provém da instituição que alega representar.

Os controlos relevantes podem incluir:

• certificados digitais institucionais;
• Pares de chaves SSH pública/privada;
• certificados TLS mútuos;
• credenciais de API;
• lista de endereços IP autorizados;
• autenticação por VPN;
• módulos de segurança de hardware;
• fixação de certificados (certificate pinning), quando adequado;
• autenticação administrativa multifator;
• contas de serviço controladas;
• controlos de acesso baseados em funções; e
• segregação dos ambientes de produção e de teste.

Um endereço IP, por si só, não constitui prova adequada da identidade institucional.

Do mesmo modo, a posse de um ponto de acesso, de um início de sessão num servidor, de uma credencial de API ou de uma palavra-passe de ficheiro ZIP não estabelece a propriedade dos fundos subjacentes.

6. Encriptação

A confidencialidade deve, em regra, ser estabelecida a mais do que um nível.

Cifragem em Trânsito

O canal de comunicações deve ser cifrado com recurso a um protocolo contemporâneo devidamente configurado, como o TLS ou o SSH.

Protege a informação em trânsito.

Encriptação da Carga Útil

Sempre que exigido, o próprio pacote da transação pode ainda ser cifrado.

Esta solução assegura a proteção da informação financeira independentemente do canal de transporte e pode reduzir de forma significativa a exposição nos casos em que os ficheiros são temporariamente armazenados, encaminhados através de infraestruturas intermédias, arquivados ou tratados de forma assíncrona.

Cifragem em repouso

Os ficheiros a aguardar processamento devem ser protegidos em ambientes de armazenamento controlados, com restrições de acesso adequadas e cifragem em repouso.

A cifragem, contudo, assegura a confidencialidade. Não estabelece a validade financeira da transação.

7. Integridade Criptográfica

A instituição recetora deve igualmente ser capaz de determinar se o pacote transmitido foi alterado após a sua criação.

Pode, por conseguinte, ser gerado um hash criptográfico para o pacote ou para os ficheiros que o compõem.

Por exemplo:

Pacote de transação original
→ geração do hash criptográfico
→ transmissão do pacote
→ o sistema recetor calcula de forma independente o hash
→ comparação do hash calculado com o hash transmitido ou assinado

Uma divergência indica que o pacote recebido não é criptograficamente idêntico ao pacote originalmente autenticado.

Podem ser utilizados algoritmos de hash criptográficos contemporâneos, como membros das famílias SHA-2 ou SHA-3, consoante a implementação, para a verificação da integridade.

8. Assinaturas Digitais

Uma assinatura digital desempenha uma função materialmente distinta da encriptação.

A cifragem protege a confidencialidade.

O hashing contribui para estabelecer a integridade.

Uma assinatura digital corretamente implementada pode contribuir para estabelecer:

1. autenticidade - o pacote foi assinado com a chave privada correspondente;
2. integridade - os dados assinados não foram posteriormente alterados; e
3. responsabilização – a assinatura pode ser associada à credencial institucional relevante, sujeita à infraestrutura de chave pública (PKI) e ao quadro de governação aplicáveis.

A instituição recetora deve verificar a assinatura, confrontando-a com o certificado de confiança ou a chave pública correspondente, antes de a instrução de transação ser submetida a processamento de pagamento.

As chaves privadas de assinatura devem ser adequadamente protegidas, de preferência através de uma infraestrutura institucional de gestão de chaves e, quando justificado, de Hardware Security Modules.

9. Proteção contra Repetição e Duplicação

A transmissão de ficheiros financeiros exige controlos que impeçam que a mesma instrução válida seja submetida repetidamente.

Uma arquitetura adequadamente concebida deve, por conseguinte, incorporar identificadores únicos de transação e controlos apropriados, tais como:

• identificadores únicos de mensagem;
• identificadores únicos de transação;
• registos de data e hora;
• números de sequência;
• identificadores de ficheiros;
• deteção de mensagens duplicadas;
• controlos de idempotência;
• registos do estado de processamento; e
• reconciliação com instruções previamente processadas.

A instituição recetora deve rejeitar, colocar em quarentena ou investigar instruções duplicadas, de acordo com o procedimento operacional acordado.

10. Validação de Ficheiros

A receção bem-sucedida de um ficheiro deve dar início à validação, e não a uma liquidação automática.

Um ambiente de tratamento seguro pode submeter o pacote a vários controlos sequenciais:

Fase 1 – Validação do Transporte

Confirmação de que o envio chegou através de um canal autorizado.

Fase 2 – Autenticação do Ponto Terminal

Confirmação do sistema emissor e das credenciais institucionais.

Fase 3 – Controlos de Malware e de Segurança de Ficheiros

Inspeção do arquivo e dos ficheiros que o compõem antes da sua integração na infraestrutura de pagamentos.

Fase 4 – Verificação criptográfica

Validação de hashes, assinaturas e certificados.

Fase 5 – Validação Estrutural

Confirmação de que os ficheiros cumprem o esquema acordado, as convenções de nomenclatura, a codificação de caracteres e a especificação de dados.

Fase 6 – Validação Semântica

Confirmação de que os campos de pagamento obrigatórios estão presentes e são internamente coerentes.

Fase 7 – Validação da Transação

Validação da divisa, do montante, das contas, das informações de encaminhamento, das referências da transação e das instruções de liquidação.

Fase 8 – Validação de Conformidade

Controlos de AML, de sanções, de KYC/KYB, de monitorização de transações e outros controlos aplicáveis.

Fase 9 – Validação da Liquidação

Confirmação de que existe efetivamente um mecanismo através do qual o valor financeiro correspondente pode ser liquidado.

Só depois de concluídos estes controlos deve uma instrução prosseguir para execução, de acordo com os procedimentos aplicáveis da instituição recetora.

11. O Reconhecimento Não Equivale à Liquidação

Um ambiente IP ZIP pode gerar vários avisos de receção técnicos.

Por exemplo:

ACK – Ficheiro recebido

Isto estabelece apenas que o ponto de receção obteve o pacote.

ACK – Ficheiro autenticado

Tal comprova que os controlos de autenticação foram concluídos com êxito.

ACK – Ficheiro validado

Fica assim estabelecido que o pacote satisfez a validação estrutural ou técnica aplicável.

ACK – Instrução aceite

Tal poderá comprovar que a instrução de pagamento entrou no fluxo de processamento da instituição recetora.

Nenhum destes estados significa necessariamente que:

LIQUIDADO

A liquidação exige um evento financeiro distinto.

A distinção é comparável à das mensagens financeiras convencionais, em que a entrega e a aceitação bem-sucedidas de uma mensagem de pagamento têm de ser distinguidas da liquidação definitiva da obrigação monetária subjacente.

12. Liquidação da Transação Subjacente

Uma vez autenticada, validada, aceite e autorizada uma instrução de pagamento IP ZIP, o valor monetário subjacente tem de ser liquidado através de uma infraestrutura financeira adequada.

Consoante as moedas, as instituições e as jurisdições envolvidas, a liquidação pode ser efetuada através de:

• banca correspondente;
• Contas Nostro/Vostro;
• contas junto do banco central;
• Infraestruturas RTGS;
• sistemas de compensação reconhecidos;
• sistemas de pagamento nacionais;
• infraestruturas de pagamentos instantâneos;
• bancos correspondentes de liquidação; ou
• outro mecanismo de liquidação legal e operacionalmente reconhecido.

14. Princípio de Segurança

O IFB aplica uma distinção fundamental a todas as metodologias alternativas de transferência:

A transmissão segura demonstra que os dados podem ser transmitidos em segurança. Não demonstra que os fundos possam ser liquidados.

• A encriptação não comprova a existência de fundos.
• Uma assinatura digital não comprova a existência de fundos.
• Um saldo num servidor não constitui prova de fundos.
• Um ficheiro de transações não comprova a existência de fundos.
• A ingestão bem-sucedida de um ficheiro não constitui prova de fundos.
• Um aviso de receção técnico não constitui prova de liquidação.

A questão financeira decisiva continua a ser se a instituição de origem dispõe de liquidez verificada e de uma via operacional de liquidação capaz de entregar o valor monetário correspondente através de infraestruturas bancárias reconhecidas.

15. Quadro de Aceitação do IFB

O IFB poderá considerar transmissões IP ZIP apenas para contrapartes institucionais aprovadas e clientes aceites, após análise técnica, jurídica e de conformidade satisfatória.

Antes de ser estabelecida a conectividade em ambiente de produção, o IFB poderá exigir a verificação de:

• a instituição de origem;
• autoridade institucional para transmitir a operação;
• titularidade efetiva e partes na transação;
• origem e legitimidade dos fundos;
• finalidade económica subjacente;
• infraestrutura de envio e receção;
• titularidade dos pontos terminais;
• IP e arquitetura de rede;
• metodologia de autenticação;
• certificados e credenciais criptográficas;
• normas de encriptação;
• formato do ficheiro e esquema;
• estrutura das mensagens de pagamento;
• metodologia de identificação de transações;
• protocolo de aviso de receção;
• controlos de duplicação e de repetição;
• tratamento de exceções;
• procedimentos de reconciliação;
• relações de correspondência bancária;
• contas de liquidação;
• mecanismos de liquidez; e
• a via de liquidação final.

A interoperabilidade técnica, por si só, não é suficiente.

O IFB não considerará a transmissão bem-sucedida de um pacote IP ZIP como receção de fundos. A transação só se considera financeiramente concluída quando o valor correspondente tiver sido liquidado com êxito através da infraestrutura bancária ou de liquidação acordada e a liquidação puder ser reconciliada de forma independente.

Princípio Fundamental

O IP ZIP é a transmissão segura de uma instrução. A liquidação é a movimentação do valor financeiro correspondente.

Os dois processos podem integrar o mesmo fluxo de trabalho de uma transação, mas não constituem o mesmo evento.

Na terminologia bancária institucional:

Transmissão da mensagem → autenticação → validação → aceitação → execução → liquidação → reconciliação

Apenas a conclusão do processo de liquidação aplicável determina que a componente monetária da transação foi concluída.

A terminologia associada a métodos de transferência alternativos ou legados deve ser interpretada no contexto da infraestrutura bancária. Esses termos podem descrever canais de comunicação, métodos de processamento interno ou práticas históricas, mas não substituem a exigência de instituições regulamentadas, sistemas de pagamento reconhecidos e procedimentos formais de liquidação.

Qualquer transferência, independentemente da terminologia, tem de ser, em última instância, processada, compensada e reconciliada no âmbito do sistema financeiro estabelecido.

Se pretender saber mais sobre como transferir fundos ou ativos para as suas contas junto de nós, contacte Marie Mayer.