IP to IP (IPIP)

IP to IP transfers refer to a part of the process of transferring currency or assets, liabilities and equities from corresponding bank accounts or data between different financial institutions or systems by utilizing Internet Protocol (IP) addresses.  In the context of financial transactions, The IP address is a unique numerical identifier assigned to every device connected to the internet, and it is used to route information between different systems. IP to IP transfers in banking involve the direct communication between two systems using their respective IP addresses to facilitate a financial transaction. Special authentication and authorization methods are used on top to secure information integrity and security. 

However, it's important to note that IP to IP transfers are not common or recommended in the banking industry for a variety of reasons, including security, reliability, and compliance concerns. The following points provide some context on these concerns:

1. Security: IP to IP transfers can be less secure compared to established banking networks, such as SWIFT or ACH, which implement multiple layers of security, encryption, and authentication. Direct communication between two IP addresses may expose sensitive information to potential security threats, including hacking, phishing, or man-in-the-middle attacks.
2. Reliability: The use of IP to IP transfers does not guarantee the reliability of the transaction, as there are no universally recognized standards or protocols in place for IP-based transfers in the banking industry. This may lead to potential issues with transaction processing, tracking, and reconciliation.
3. Compliance: Banks and financial institutions are subject to numerous regulations and requirements, including Anti-Money Laundering (AML) and Know Your Customer (KYC) policies. IP to IP transfers may not adhere to these regulatory requirements, potentially exposing the involved parties to legal and financial risks.

Instead of IP to IP transfers, banks and financial institutions prefer to use established networks, such as SWIFT, RTGS or ACH/Instant Payment and messaging standards like ISO 20022 to facilitate secure, reliable, and compliant fund transfers between different institutions.

Protocols for IPIP

1. FIX (Financial Information eXchange): Primarily used in the finance industry for communication and exchange of financial information. In the context of IPIP, FIX facilitates real-time exchange of financial data, supporting high-speed transactions. Its relevance to HPC environments lies in the need for processing large volumes of financial data rapidly, where high-performance computing can significantly enhance data processing and analysis capabilities.
2. EBICS (Electronic Banking Internet Communication Standard): A protocol used for secure transmission of payment transactions. In IPIP, EBICS ensures secure and standardized communication between banking institutions. HPC can be utilized to handle the complex calculations and large datasets involved in banking transactions, improving processing speed and efficiency.
3. ZENGIN: A Japanese banking protocol for domestic fund transfers and direct debits. In IPIP scenarios, ZENGIN enables efficient and secure handling of high-volume domestic transactions. HPC environments can process these transactions more quickly, especially when dealing with peak load periods.
4. AS2 (Applicability Statement 2): Used for secure data transport over the Internet. In IPIP, AS2 is crucial for transmitting EDI (Electronic Data Interchange) messages securely. HPC can enhance the capability to process large volumes of EDI messages, particularly in industries like retail and manufacturing where EDI is prevalent.
5. SNMPv3 (Simple Network Management Protocol version 3): Enhances the security and integrity of management data in network management systems. In IPIP, SNMPv3 is instrumental for securely monitoring and managing network devices. Within HPC environments, it can be used to monitor and manage extensive networks, ensuring optimal performance and security.
6. Kerberos: A network authentication protocol designed for a client-server model, providing strong authentication and secure communications. In IPIP, Kerberos can secure the transfer of sensitive information. In HPC, it ensures that the data and resources are accessed only by authenticated users, crucial for maintaining the integrity of high-performance computing tasks.
7. OAuth: An open standard for access delegation, commonly used for token-based authentication and authorization. In IPIP, OAuth enables secure, delegated access to resources. In HPC environments, OAuth can manage access to computing resources and data, ensuring secure and efficient resource utilization.
8. LDAP over SSL/TLS (Lightweight Directory Access Protocol over Secure Socket Layer/Transport Layer Security): Enhances the security of LDAP communications. In IPIP, this protocol ensures secure access to directory services. For HPC environments, LDAP over SSL/TLS can be used to securely manage user identities and control access to computing resources.
9. SCP and SFTP over SSH (Secure Copy Protocol and Secure File Transfer Protocol over Secure Shell): These protocols are used for secure file transfer. In the context of HPC, they are crucial for securely transferring large datasets and code between computing nodes. SCP and SFTP over SSH ensure data integrity and security, which is vital in HPC environments where data sensitivity is often high.

Each of these protocols plays a unique role in facilitating secure, efficient, and reliable data exchange and communication, which are key components in IPIP  environments. Their implementation under HPC ensures robust security and high-performance data processing capabilities. In IPIP transactions involving the transfer of currency, bank assets, liabilities and equity, the mentioned protocols are necessary but not sufficient for the completion of the financial transactions:

IPIP Funds Transfer to us

To alleviate some compliance concerns when an MT 103 was sent per IPIP instead of SWIFT to us, you could consider your sending bank including the following additional information in the MT 202 COV within the correspondent bank to correspondent bank transmission of funds, where the format allows:

1. Ordering Customer Information: Provide details of the ordering customer, similar to Field 50 in MT 103. This can include name, address, and account number.
2. Beneficiary Information: Include details of the beneficiary, mimicking Field 59 in MT 103. This should have the beneficiary name, address, and account numbe
3. Purpose of Payment: Explicitly state the reason for the transaction, which could alleviate some Anti-Money Laundering (AML) concerns.
4. Regulatory Reporting Information: If your jurisdiction requires, include codes or identifiers for regulatory reporting.
5. Reference to IPIP MT 103: A specific mention that the MT 202 COV is tied to a IPIP MT 103, can provide context to the intermediary bank.
6. Contact Information: Include specific contact details for the compliance department or transaction manager responsible for this payment, in case the receiving bank needs immediate clarification.
7. Special Handling Instructions: Any extra instructions for the receiving bank that could facilitate the identification and proper handling of the transferred funds.
8. Charges and Fees Information: In absence of an SWIFT MT 103, it might be beneficial to clarify who will bear transaction-related charges to prevent misunderstandings.
9. Additional Identifiers: Include any additional transaction identifiers that can link the MT 202 COV to the IPIP MT 103, such as invoice numbers or internal transaction IDs.

Note on Compliance

Including additional information in the MT 202 COV may not fully mitigate compliance risks, especially AML and CFT (Combating the Financing of Terrorism) checks that are typically addressed with a SWIFT MT 103 message and it's important to ensure that the modified MT 202 COV still complies with applicable standards and interbank agreements.

The Main Differences Between Communication Servers and Ledger/Account Servers in Banks

In the realm of banking technology, servers play a pivotal role in ensuring the smooth operation of financial transactions and record-keeping. Two primary types of servers that banks rely on are communication servers and ledger/account servers. Despite both being crucial, they serve distinct purposes and handle different types of data.

Communication Servers

Communication servers are the backbone of secure data exchange between banks and financial institutions. Here are the key functions and features of communication servers:

1. Secure Data Exchange: These servers facilitate secure data exchange, ensuring that sensitive financial information can be transmitted between institutions without compromise.
2. Protocols and Standards: They utilize standardized protocols such as SWIFT, Sepa  or ACH, etc. for interbank communication, ensuring uniformity and reliability across different platforms.
3. Encryption and Authentication: To maintain security, communication servers employ advanced encryption methods and stringent authentication protocols, safeguarding data during transmission.
4. Transaction Handling: Primarily, they handle transaction requests, messages, and instructions, acting as intermediaries that pass along the necessary information for transactions.
5. No Fund Movement:  Importantly, these servers do not move funds or update account balances directly; they only facilitate the communication required for such actions.

Ledger/Account Servers

Ledger/account servers, on the other hand, are the custodians of a bank's financial records. Here are their main characteristics:

1. Financial Record Maintenance: These servers store and maintain the core financial records of the bank, ensuring every transaction is accurately recorded.
2. Transaction Recording: They record all transactions, including debits and credits, and are responsible for updating and storing current account balances.
3. General Ledger Management: Ledger servers manage the bank's general ledger along with individual customer accounts, providing a comprehensive view of financial health.
4. Data Integrity: Ensuring data consistency and integrity is paramount, as these records are essential for accurate financial reporting and compliance.
5. Robust Security Measures: Given the sensitivity of the data, ledger servers typically employ more stringent security measures, including additional layers of encryption and rigorous access controls.

The communication server initiates and facilitates transactions, but the ledger server ultimately records and reflects those transactions after validation in the bank's books.

In contemporary banking systems, these functions are often integrated, with secure intra-bank communication protocols working in tandem with ledger management systems. This integration ensures real-time updates and consistency across the bank's entire financial ecosystem, enhancing both efficiency and security. Many banks use a combination of on-premises and cloud-based servers to balance security, compliance, and scalability requirements.

Actual Transfer of Assets, Liabilities and Equities: In asset, liabilities and equity transactions, it's crucial to record these transfers with the CSDs. CSDs are responsible for maintaining the legal record of securities ownership, a process beyond the scope of the initial communication protocols. The transfer of assets and equities also impacts the banks' financial statements, altering liabilities, assets, and equity balances. This financial reporting to the involved controlling authorities and the necessary compliance aspect is beyond the data transmission capabilities of the protocols and requires additional financial and regulatory processes.

In essence, while protocols are vital for the secure and efficient exchange of information in IPIP transactions, the complete process involves additional systems for actual currency, asset, liabilities and equities movement, settlement, legal recording and financial reporting, ensuring that the entire transaction is executed in compliance with regulatory banking standards. 

IP ZIP Transfer

Secure File-Based Transmission of Institutional Payment Instructions

An IP ZIP Transfer is best understood as a secure, file-based method for transmitting structured payment instructions and associated transaction data directly between authenticated institutional systems over an Internet Protocol network.

The terminology requires particular precision.

An IP ZIP transmission is not a clearing system, settlement system, payment rail, or independent mechanism for transferring monetary value. The ZIP archive is a transport container. The IP connection is the communications channel. The information contained within the archive constitutes an instruction, dataset, or transaction message.

Accordingly:

IP ZIP transmits payment information and instructions. It does not, by itself, settle funds.

Conceptually, this is comparable to the distinction applicable to an ISO 20022 pacs.008 FinancialInstitutionCreditTransfer message. A pacs.008 can carry a highly structured interbank credit-transfer instruction, but the message itself must not be confused with the ultimate movement and settlement of central-bank money, commercial-bank money, or correspondent-account balances.

The same principle applies to an IP ZIP transmission.

2. The ZIP File as a Secure Transaction Container

The ZIP component serves primarily as a containerisation and packaging mechanism.

Rather than transmitting individual transaction components separately, the originating institution may assemble the relevant files into a single controlled package.

Depending upon the agreed bilateral specification, such a package may contain:

• structured payment instructions;
• XML payment messages;
• ISO 20022-compatible datasets;
• JSON transaction objects;
• CSV or fixed-format transaction records;
• proprietary interbank payment files;
• debtor and creditor information;
• originating and beneficiary account information;
• transaction identifiers;
• currency and amount information;
• requested execution and value dates;
• correspondent-bank instructions;
• intermediary-bank information;
• remittance information;
• settlement-routing information;
• compliance documentation;
• KYC or KYB references;
• source-of-funds information;
• transaction manifests;
• digital signatures;
• cryptographic hashes;
• certificates;
• timestamps;
• reconciliation files; and
• control totals.

The archive may therefore contain both the primary payment instruction and the ancillary information required to authenticate, validate, process and reconcile that instruction.

Compression is technically incidental. The principal purpose is controlled packaging and transmission.

A ZIP archive should consequently never be treated as evidence that funds represented within the archive exist, are available, are unencumbered, or have been settled.

3. Structured Payment Instruction

Where appropriately designed, the payment instruction contained within an IP ZIP package may perform a function analogous to conventional structured financial messaging.

For example, an institution could transmit an XML instruction containing fields corresponding to information ordinarily found within an ISO 20022 pacs.008 message, including:

• message identification;
• creation date and time;
• number of transactions;
• settlement information;
• instructing agent;
• instructed agent;
• debtor;
• debtor account;
• debtor agent;
• creditor agent;
• creditor;
• creditor account;
• instructed amount;
• currency;
• charge bearer;
• payment identification;
• end-to-end identification; and
• remittance information.

The crucial distinction is that the data structure does not determine the settlement mechanism.

A technically valid payment instruction can be received, authenticated and accepted by the receiving system while the corresponding financial settlement remains outstanding.

Thus:

Instruction received ≠ funds received

Instruction authenticated ≠ funds settled

File successfully imported ≠ beneficiary credited with final funds

Server acknowledgement ≠ settlement confirmation

This distinction is fundamental to IFB’s treatment of alternative transfer methodologies.

4. Transmission Protocols

Institutional IP ZIP transmissions should occur exclusively through a controlled and authenticated communications environment.

Depending upon the bilateral technical arrangement, transmission may employ technologies such as:

SFTP

Secure File Transfer Protocol over SSH provides encrypted transport, server authentication and controlled user authentication.

Public-key authentication should ordinarily be preferred to password-only authentication for institutional connectivity.

FTPS

FTP may be protected through TLS where legacy infrastructure requires it, provided that appropriate certificate validation, encryption standards and access controls are implemented.

HTTPS / REST API

The package may be transmitted through an authenticated HTTPS endpoint or API architecture using TLS and appropriate application-level authentication.

Mutual TLS

For higher-assurance institutional connections, mutual TLS (mTLS) permits both endpoints to authenticate each other using digital certificates.

This provides materially stronger protection against unauthorised endpoints than unilateral server authentication alone.

VPN

A site-to-site IPSec or equivalent VPN may establish an encrypted private tunnel between the participating institutions before the application-level transmission occurs.

Dedicated Private Connectivity

Where transaction volumes, security requirements or institutional risk profiles justify it, dedicated or private network connectivity may supplement or replace transmission across the public Internet.

The precise protocol must be agreed bilaterally before operational activation.

5. Endpoint Authentication

The receiving institution must establish that the transmission originates from the institution it purports to represent.

Relevant controls may include:

• institutional digital certificates;
• SSH public/private key pairs;
• mutual TLS certificates;
• API credentials;
• IP allow-listing;
• VPN authentication;
• hardware security modules;
• certificate pinning where appropriate;
• multi-factor administrative authentication;
• controlled service accounts;
• role-based access controls; and
• segregation of production and test environments.

An IP address alone is not adequate evidence of institutional identity.

Likewise, possession of an endpoint, server login, API credential or ZIP password does not establish ownership of the underlying funds.

6. Encryption

Confidentiality should ordinarily be established at more than one level.

Transport Encryption

The communications channel should be encrypted using an appropriately configured contemporary protocol such as TLS or SSH.

This protects information in transit.

Payload Encryption

Where required, the transaction package itself may additionally be encrypted.

This provides protection of the financial information independently of the transport channel and can materially reduce exposure where files are temporarily stored, routed through intermediary infrastructure, archived or processed asynchronously.

Encryption at Rest

Files awaiting processing should be protected within controlled storage environments with appropriate access restrictions and encryption at rest.

Encryption, however, establishes confidentiality. It does not establish the financial validity of the transaction.

7. Cryptographic Integrity

The receiving institution must also be capable of determining whether the transmitted package has been altered after creation.

A cryptographic hash may therefore be generated for the package or its constituent files.

For example:

Original transaction package
→ cryptographic hash generated
→ package transmitted
→ receiving system independently calculates hash
→ calculated hash compared with transmitted or signed hash

A mismatch indicates that the package received is not cryptographically identical to the package originally authenticated.

Contemporary cryptographic hash algorithms, such as members of the SHA-2 or SHA-3 families where appropriate to the implementation, may be employed for integrity verification.

8. Digital Signatures

A digital signature provides a materially different function from encryption.

Encryption protects confidentiality.

Hashing assists in establishing integrity.

A properly implemented digital signature can assist in establishing:

1. authenticity - the package was signed using the relevant private key;
2. integrity - the signed data has not subsequently been altered; and
3. accountability - the signature can be associated with the relevant institutional credential, subject to the applicable PKI and governance framework.

The receiving institution should verify the signature against the corresponding trusted certificate or public key before the transaction instruction enters payment processing.

Private signing keys should be appropriately protected, preferably through institutional key-management infrastructure and, where warranted, Hardware Security Modules.

9. Replay and Duplication Protection

Financial file transmission requires controls against the same valid instruction being submitted repeatedly.

An appropriately designed architecture should therefore incorporate unique transaction identifiers and appropriate controls such as:

• unique message IDs;
• unique transaction IDs;
• timestamps;
• sequence numbers;
• file identifiers;
• duplicate-message detection;
• idempotency controls;
• processing-status registers; and
• reconciliation against previously processed instructions.

The receiving institution should reject, quarantine or investigate duplicate instructions according to the agreed operating procedure.

10. File Validation

Successful receipt of a file should initiate validation, not automatic settlement.

A secure processing environment may subject the package to several sequential controls:

Stage 1 - Transport Validation

Confirmation that the package arrived through an authorised channel.

Stage 2 - Endpoint Authentication

Confirmation of the transmitting system and institutional credentials.

Stage 3 - Malware and File-Security Controls

Inspection of the archive and its constituent files before ingestion into payment infrastructure.

Stage 4 - Cryptographic Verification

Validation of hashes, signatures and certificates.

Stage 5 - Structural Validation

Confirmation that the files comply with the agreed schema, naming conventions, character encoding and data specification.

Stage 6 - Semantic Validation

Confirmation that mandatory payment fields are present and internally coherent.

Stage 7 - Transaction Validation

Validation of currency, amount, accounts, routing information, transaction references and settlement instructions.

Stage 8 - Compliance Validation

AML, sanctions, KYC/KYB, transaction-monitoring and other applicable controls.

Stage 9 - Settlement Validation

Confirmation that an actual mechanism exists through which the corresponding financial value can be settled.

Only after these controls have been completed should an instruction proceed to execution according to the receiving institution’s applicable procedures.

11. Acknowledgement Is Not Settlement

An IP ZIP environment may generate several technical acknowledgements.

For example:

ACK - File received

This establishes only that the receiving endpoint obtained the package.

ACK - File authenticated

This establishes that authentication controls were successfully completed.

ACK - File validated

This establishes that the package satisfied the applicable structural or technical validation.

ACK - Instruction accepted

This may establish that the payment instruction has entered the receiving institution’s processing workflow.

None of these states necessarily means:

SETTLED

Settlement requires a separate financial event.

The distinction is comparable to conventional financial messaging, where successful delivery and acceptance of a payment message must be distinguished from final settlement of the underlying monetary obligation.

12. Settlement of the Underlying Transaction

Once an IP ZIP payment instruction has been authenticated, validated, accepted and authorised, the underlying monetary value must be settled through an appropriate financial infrastructure.

Depending upon the currencies, institutions and jurisdictions involved, settlement may take place through:

• correspondent banking;
• Nostro/Vostro accounts;
• central-bank accounts;
• RTGS infrastructure;
• recognised clearing systems;
• domestic payment systems;
• instant-payment infrastructures;
• correspondent settlement banks; or
• another legally and operationally recognised settlement arrangement.

.14. Security Principle

IFB applies a fundamental distinction to all alternative transfer methodologies:

Secure transmission proves that data can be securely transmitted. It does not prove that money can be settled.

• Encryption does not prove funds.
• A digital signature does not prove funds.
• A server balance does not prove funds.
• A transaction file does not prove funds.
• Successful file ingestion does not prove funds.
• A technical acknowledgement does not prove settlement.

The decisive financial question remains whether the originating institution has verified liquidity and an operational settlement pathway capable of delivering the corresponding monetary value through recognised banking infrastructure.

15. IFB Acceptance Framework

IFB may consider IP ZIP transmissions only for approved institutional counterparties and accepted clients following satisfactory technical, legal and compliance review.

Before production connectivity is established, IFB may require verification of:

• the originating institution;
• institutional authority to transmit the transaction;
• beneficial ownership and transaction parties;
• source and legitimacy of funds;
• underlying economic purpose;
• sending and receiving infrastructure;
• endpoint ownership;
• IP and network architecture;
• authentication methodology;
• certificates and cryptographic credentials;
• encryption standards;
• file format and schema;
• payment-message structure;
• transaction identification methodology;
• acknowledgement protocol;
• duplicate and replay controls;
• exception handling;
• reconciliation procedures;
• correspondent relationships;
• settlement accounts;
• liquidity arrangements; and
• the ultimate settlement pathway.

Technical interoperability alone is insufficient.

IFB will not treat the successful transmission of an IP ZIP package as receipt of funds. The transaction is financially complete only when the corresponding value has been successfully settled through the agreed banking or settlement infrastructure and the settlement can be independently reconciled.

Fundamental Principle

IP ZIP is the secure transmission of an instruction. Settlement is the movement of the corresponding financial value.

The two processes may form parts of the same transaction workflow, but they are not the same event.

In institutional banking terminology:

Message transmission → authentication → validation → acceptance → execution → settlement → reconciliation

Only the completion of the applicable settlement process establishes that the monetary leg of the transaction has been completed.

Terminology associated with alternative or legacy transfer methods should be interpreted within the context of banking infrastructure. Such terms may describe communication channels, internal processing methods, or historical practices, but they do not replace the requirement for regulated institutions, recognised payment systems, and formal settlement procedures.

Any transfer, regardless of terminology, must ultimately be processed, cleared, and reconciled within the established financial system.

If you want to know more about how to transfer funds or assets to your accounts with us, please get in contact with Marie Mayer.