IP/IP- en IPZip-overboekingen

IP naar IP (IPIP)

IP-naar-IP-overdrachten verwijzen naar een onderdeel van het proces waarbij valuta, activa, passiva en eigen vermogen of gegevens van correspondentbankrekeningen worden overgedragen tussen verschillende financiële instellingen of systemen met gebruikmaking van Internet Protocol (IP)-adressen. In de context van financiële transacties is het IP-adres een unieke numerieke identificatiecode die aan elk met het internet verbonden apparaat is toegewezen en wordt gebruikt om informatie tussen verschillende systemen te routeren. IP-naar-IP-overdrachten in het bankwezen omvatten de directe communicatie tussen twee systemen via hun respectieve IP-adressen om een financiële transactie mogelijk te maken. Daarbovenop worden specifieke authenticatie- en autorisatiemethoden toegepast om de integriteit en de veiligheid van de informatie te waarborgen.

Het is echter belangrijk op te merken dat IP-naar-IP-overboekingen in de banksector niet gebruikelijk of aanbevolen zijn, om uiteenlopende redenen, waaronder beveiligings-, betrouwbaarheids- en compliancezorgen. De volgende punten geven enige context bij deze zorgen:

1. Beveiliging: IP-naar-IP-overdrachten kunnen minder veilig zijn dan gevestigde banknetwerken, zoals SWIFT of ACH, die meerdere lagen van beveiliging, versleuteling en authenticatie toepassen. Directe communicatie tussen twee IP-adressen kan gevoelige informatie blootstellen aan mogelijke beveiligingsdreigingen, waaronder hacking, phishing of man-in-the-middle-aanvallen.
2. Betrouwbaarheid: Het gebruik van IP-naar-IP-overboekingen waarborgt de betrouwbaarheid van de transactie niet, aangezien er in de bankensector geen algemeen erkende standaarden of protocollen bestaan voor IP-gebaseerde overboekingen. Dit kan leiden tot mogelijke problemen bij de verwerking, de tracering en de afstemming van transacties.
3. Compliance: Banken en financiële instellingen zijn onderworpen aan tal van regels en vereisten, waaronder het beleid inzake Anti-Money Laundering (AML) en Know Your Customer (KYC). IP-naar-IP-overboekingen voldoen mogelijk niet aan deze regelgevende vereisten, waardoor de betrokken partijen mogelijk worden blootgesteld aan juridische en financiële risico's.

In plaats van overboekingen van IP naar IP geven banken en financiële instellingen de voorkeur aan gevestigde netwerken, zoals SWIFT, RTGS of ACH/Instant Payment, en aan berichtenstandaarden zoals ISO 20022, om veilige, betrouwbare en conforme geldoverboekingen tussen verschillende instellingen te faciliteren.

De belangrijkste verschillen tussen communicatieservers en grootboek-/rekeningservers bij banken

In de banktechnologie spelen servers een doorslaggevende rol bij het waarborgen van de vlotte werking van financiële transacties en de registratie daarvan. Twee hoofdtypen servers waarop banken vertrouwen zijn communicatieservers en grootboek-/rekeningservers. Hoewel beide van cruciaal belang zijn, dienen zij verschillende doeleinden en verwerken zij verschillende soorten gegevens.

Communicatieservers

Communicatieservers vormen de ruggengraat van de beveiligde gegevensuitwisseling tussen banken en financiële instellingen. Hieronder volgen de belangrijkste functies en kenmerken van communicatieservers:

1. Veilige gegevensuitwisseling: Deze servers maken veilige gegevensuitwisseling mogelijk, waardoor gevoelige financiële informatie tussen instellingen kan worden verzonden zonder dat de veiligheid in het gedrang komt.
2. Protocollen en standaarden: zij maken gebruik van gestandaardiseerde protocollen zoals SWIFT, SEPA of ACH, enz. voor interbancaire communicatie, wat zorgt voor uniformiteit en betrouwbaarheid over verschillende platforms heen.
3. Encryptie en authenticatie: Om de beveiliging te waarborgen, maken communicatieservers gebruik van geavanceerde encryptiemethoden en strikte authenticatieprotocollen, waarmee gegevens tijdens de verzending worden beschermd.
4. Transactieafhandeling: In de eerste plaats verwerken zij transactieverzoeken, berichten en instructies en fungeren zij als intermediairs die de benodigde informatie voor transacties doorgeven.
5. Geen geldbewegingen: Deze servers verplaatsen uitdrukkelijk geen middelen en werken rekeningsaldi niet rechtstreeks bij; zij faciliteren uitsluitend de communicatie die voor dergelijke handelingen vereist is.

Grootboek-/rekeningservers

Grootboek- en rekeningservers zijn daarentegen de bewaarders van de financiële gegevens van een bank. Hun belangrijkste kenmerken zijn:

1. Bijhouden van financiële gegevens: Deze servers slaan de kernadministratie van de bank op en houden deze bij, zodat elke transactie nauwkeurig wordt vastgelegd.
2. Vastlegging van transacties: Zij leggen alle transacties vast, inclusief debiteringen en crediteringen, en zijn verantwoordelijk voor het bijwerken en bewaren van de actuele rekeningsaldi.
3. Grootboekbeheer: Grootboekservers beheren het algemene grootboek van de bank en de individuele cliëntrekeningen en bieden zo een volledig overzicht van de financiële gezondheid.
4. Data-integriteit: Het waarborgen van consistentie en integriteit van gegevens is essentieel, aangezien deze registraties onmisbaar zijn voor een juiste financiële rapportage en voor compliance.
5. Strenge beveiligingsmaatregelen: gezien de gevoeligheid van de gegevens hanteren ledgerservers doorgaans strengere beveiligingsmaatregelen, waaronder extra lagen van versleuteling en strikte toegangscontroles.

De communicatieserver initieert en faciliteert transacties, maar de grootboekserver registreert en weerspiegelt die transacties uiteindelijk na validatie in de boeken van de bank.

In hedendaagse banksystemen zijn deze functies vaak geïntegreerd, waarbij beveiligde intrabankcommunicatieprotocollen samenwerken met systemen voor grootboekbeheer. Deze integratie zorgt voor actualisering in real time en consistentie binnen het gehele financiële ecosysteem van de bank, waardoor zowel de efficiëntie als de veiligheid toeneemt. Veel banken gebruiken een combinatie van lokale en cloudgebaseerde servers om beveiliging, compliance en schaalbaarheid in evenwicht te brengen.

Daadwerkelijke overdracht van activa, passiva en eigen vermogen: Overdrachten van effecten worden geregistreerd door centrale effectenbewaarinstellingen (CSD's), die het wettelijke eigendomsregister bijhouden; leningen, vaste activa en andere posities gaan over door cessie of overdrachtsovereenkomsten naar het toepasselijke recht. Beide vallen buiten het bereik van de communicatieprotocollen. De overdracht van activa en eigen vermogen heeft eveneens gevolgen voor de jaarrekening van de banken, omdat de saldi van passiva, activa en eigen vermogen wijzigen. Deze financiële verslaggeving aan de betrokken toezichthoudende autoriteiten en het noodzakelijke compliance-aspect vallen buiten de mogelijkheden van de protocollen voor gegevensoverdracht en vereisen aanvullende financiële en regelgevende processen.

In essentie zijn protocollen weliswaar onmisbaar voor de veilige en efficiënte uitwisseling van informatie bij IPIP-transacties, maar het volledige proces omvat aanvullende systemen voor de feitelijke verplaatsing van valuta, activa, verplichtingen en eigen vermogen, de afwikkeling, de juridische vastlegging en de financiële verslaggeving, zodat de gehele transactie wordt uitgevoerd in overeenstemming met de regelgevende bankstandaarden.

IP-ZIP-overdracht

Beveiligde, bestandsgebaseerde verzending van institutionele betalingsinstructies

Een IP ZIP Transfer kan het best worden begrepen als een beveiligde, bestandsgebaseerde methode voor het rechtstreeks verzenden van gestructureerde betaalinstructies en bijbehorende transactiegegevens tussen geauthenticeerde institutionele systemen via een Internet Protocol-netwerk.

De terminologie vereist bijzondere precisie.

Een IP-ZIP-transmissie is geen clearingsysteem, geen afwikkelingssysteem, geen betalingskanaal en geen zelfstandig mechanisme voor de overdracht van monetaire waarde. Het ZIP-archief is een transportcontainer. De IP-verbinding is het communicatiekanaal. De informatie in het archief vormt een instructie, dataset of transactiebericht.

Dienovereenkomstig:

IP ZIP verzendt betalingsinformatie en betalingsinstructies. Het verzorgt zelf geen financiële afwikkeling.

Conceptueel is dit vergelijkbaar met het onderscheid dat geldt voor een ISO 20022 pacs.008-bericht (FI-to-FI Customer Credit Transfer). Een pacs.008 kan een zeer gestructureerde interbancaire overboekingsinstructie bevatten, maar het bericht zelf mag niet worden verward met de uiteindelijke verplaatsing en afwikkeling van centralebankgeld, commercieel bankgeld of saldi op correspondentrekeningen.

Hetzelfde principe geldt voor een IP ZIP-transmissie.

2. Het ZIP-bestand als beveiligde transactiecontainer

Het ZIP-onderdeel dient in de eerste plaats als container- en verpakkingsmechanisme.

In plaats van de afzonderlijke onderdelen van een transactie apart te verzenden, kan de initiërende instelling de relevante bestanden samenvoegen tot één beheerst pakket.

Afhankelijk van de overeengekomen bilaterale specificatie kan een dergelijk pakket het volgende bevatten:

• gestructureerde betaalinstructies;
• XML-betaalberichten;
• ISO 20022-compatibele datasets;
• JSON-transactieobjecten;
• transactiebestanden in CSV-formaat of met vaste opmaak;
• propriëtaire interbancaire betalingsbestanden;
• gegevens over debiteur en crediteur;
• gegevens van de rekening van de opdrachtgever en van de begunstigde;
• transactie-identificatiecodes;
• informatie over valuta en bedrag;
• gewenste uitvoerings- en valutadata;
• instructies van de correspondentbank;
• gegevens van de intermediaire bank;
• betalingsinformatie;
• informatie over afwikkelingsroutering;
• compliancedocumentatie;
• KYC- of KYB-referenties;
• informatie over de herkomst van middelen;
• transactiemanifesten;
• digitale handtekeningen;
• cryptografische hashes;
• certificaten;
• tijdstempels;
• reconciliatiebestanden; en
• controletotalen.

Het archief kan daarom zowel de primaire betalingsopdracht bevatten als de aanvullende informatie die nodig is om die opdracht te authenticeren, valideren, verwerken en afstemmen.

Compressie is technisch gezien bijkomstig. Het hoofddoel is beheerste verpakking en verzending.

Een ZIP-archief mag daarom nooit worden beschouwd als bewijs dat de in het archief weergegeven middelen bestaan, beschikbaar zijn, onbezwaard zijn of zijn afgewikkeld.

3. Gestructureerde betalingsinstructie

Indien passend ontworpen, kan de betaalinstructie in een IP ZIP-pakket een functie vervullen die vergelijkbaar is met die van conventionele gestructureerde financiële berichten.

Een instelling zou bijvoorbeeld een XML-instructie kunnen verzenden met velden die overeenkomen met informatie die gewoonlijk voorkomt in een ISO 20022-bericht pacs.008, waaronder:

• berichtidentificatie;
• datum en tijdstip van aanmaak;
• aantal transacties;
• afwikkelingsgegevens;
• opdrachtgevende agent;
• opdrachtnemende agent;
• schuldenaar;
• rekening van de schuldenaar;
• bank van de debiteur (debtor agent);
• bank van de crediteur (creditor agent);
• schuldeiser;
• rekening van de schuldeiser;
• opdrachtbedrag;
• valuta;
• kostendrager;
• betalingsidentificatie;
• end-to-end-identificatie; en
• betalingsinformatie.

Het cruciale onderscheid is dat de datastructuur het afwikkelingsmechanisme niet bepaalt.

Een technisch geldige betalingsopdracht kan door het ontvangende systeem worden ontvangen, geauthenticeerd en geaccepteerd, terwijl de bijbehorende financiële afwikkeling nog openstaat.

Dus:

Ontvangen instructie ≠ ontvangen middelen

Geauthenticeerde instructie ≠ afgewikkelde middelen

Bestand succesvol geïmporteerd ≠ begunstigde gecrediteerd met definitieve middelen

Ontvangstbevestiging van de server ≠ bevestiging van de afwikkeling

Dit onderscheid is fundamenteel voor de wijze waarop IFB alternatieve overdrachtsmethodieken behandelt.

4. Transmissieprotocollen

Institutionele IP-ZIP-transmissies dienen uitsluitend plaats te vinden binnen een beheerste en geauthenticeerde communicatieomgeving.

Afhankelijk van de bilaterale technische afspraken kan de verzending gebruikmaken van technologieën zoals:

SFTP

Secure File Transfer Protocol over SSH biedt versleuteld transport, serverauthenticatie en gecontroleerde gebruikersauthenticatie.

Voor institutionele connectiviteit verdient authenticatie met een publieke sleutel doorgaans de voorkeur boven uitsluitend wachtwoordauthenticatie.

FTPS

FTP kan via TLS worden beveiligd waar verouderde infrastructuur dit vereist, mits passende certificaatvalidatie, versleutelingsnormen en toegangscontroles worden toegepast.

HTTPS / REST API

Het pakket kan worden verzonden via een geauthenticeerd HTTPS-eindpunt of een API-architectuur met gebruik van TLS en passende authenticatie op applicatieniveau.

Mutual TLS

Voor institutionele verbindingen met een hogere zekerheidsgraad stelt mutual TLS (mTLS) beide eindpunten in staat elkaar te authenticeren met behulp van digitale certificaten.

Dit biedt een aanzienlijk sterkere bescherming tegen niet-geautoriseerde eindpunten dan eenzijdige serverauthenticatie alleen.

VPN

Een site-to-site IPSec- of gelijkwaardige VPN-verbinding kan een versleutelde, besloten tunnel tussen de deelnemende instellingen tot stand brengen voordat de transmissie op applicatieniveau plaatsvindt.

Toegewijde private connectiviteit

Wanneer transactievolumes, beveiligingsvereisten of institutionele risicoprofielen dit rechtvaardigen, kunnen speciale of private netwerkverbindingen de verzending via het openbare internet aanvullen of vervangen.

Het exacte protocol moet vóór de operationele activering bilateraal worden overeengekomen.

5. Authenticatie van eindpunten

De ontvangende instelling moet vaststellen dat de transmissie afkomstig is van de instelling die de transmissie beweert te vertegenwoordigen.

Relevante controles kunnen onder meer zijn:

• institutionele digitale certificaten;
• SSH-sleutelparen (publiek/privé);
• wederzijdse TLS-certificaten;
• API-inloggegevens;
• IP-allowlisting;
• VPN-authenticatie;
• hardwarebeveiligingsmodules;
• waar passend certificate pinning;
• multifactorauthenticatie voor beheerders;
• gecontroleerde servicerekeningen;
• rolgebonden toegangscontroles; en
• scheiding van productie- en testomgevingen.

Een IP-adres alleen vormt geen toereikend bewijs van de identiteit van een instelling.

Evenmin geeft het bezit van een endpoint, serverlogin, API-referentie of zip-wachtwoord eigendom van de onderliggende middelen.

6. Versleuteling

Vertrouwelijkheid dient doorgaans op meer dan één niveau te worden vastgelegd.

Transportversleuteling

Het communicatiekanaal dient te worden versleuteld met een adequaat geconfigureerd modern protocol, zoals TLS of SSH.

Dit beschermt informatie tijdens de overdracht.

Payload-encryptie

Waar vereist, kan het transactiepakket zelf bovendien worden versleuteld.

Dit biedt bescherming van de financiële informatie, onafhankelijk van het transportkanaal, en kan de blootstelling aanzienlijk verminderen wanneer bestanden tijdelijk worden opgeslagen, via tussenliggende infrastructuur worden gerouteerd, worden gearchiveerd of asynchroon worden verwerkt.

Versleuteling in rust

Bestanden die op verwerking wachten, dienen te worden beschermd binnen gecontroleerde opslagomgevingen met passende toegangsbeperkingen en versleuteling in rust.

Versleuteling waarborgt echter de vertrouwelijkheid. Zij stelt de financiële geldigheid van de transactie niet vast.

7. Cryptografische integriteit

De ontvangende instelling moet ook kunnen vaststellen of het verzonden pakket na de aanmaak is gewijzigd.

Voor het pakket of de afzonderlijke bestanden daarvan kan derhalve een cryptografische hash worden gegenereerd.

Bijvoorbeeld:

Oorspronkelijk transactiepakket
→ cryptografische hash gegenereerd
→ pakket verzonden
→ ontvangend systeem berekent zelfstandig de hash
→ berekende hash vergeleken met de verzonden of ondertekende hash

Een afwijking geeft aan dat het ontvangen pakket cryptografisch niet identiek is aan het oorspronkelijk geauthenticeerde pakket.

Voor de integriteitsverificatie kunnen eigentijdse cryptografische hashalgoritmen worden gebruikt, zoals leden van de SHA-2- of SHA-3-families, afhankelijk van wat voor de implementatie passend is.

8. Digitale handtekeningen

Een digitale handtekening vervult een wezenlijk andere functie dan versleuteling.

Versleuteling beschermt de vertrouwelijkheid.

Hashing draagt bij aan het waarborgen van integriteit.

Een correct geïmplementeerde digitale handtekening kan bijdragen aan het vaststellen van:

1. authenticiteit - het pakket is ondertekend met de relevante private sleutel;
2. integriteit - de ondertekende gegevens zijn naderhand niet gewijzigd; en
3. verantwoordingsplicht - de handtekening kan worden gekoppeld aan de relevante institutionele identiteitsgegevens, onder voorbehoud van het toepasselijke PKI- en governancekader.

De ontvangende instelling dient de handtekening te verifiëren aan de hand van het bijbehorende vertrouwde certificaat of de openbare sleutel voordat de transactieopdracht in de betalingsverwerking wordt opgenomen.

Private ondertekeningssleutels dienen adequaat te worden beschermd, bij voorkeur via een institutionele infrastructuur voor sleutelbeheer en, waar gerechtvaardigd, via Hardware Security Modules.

9. Bescherming tegen herhaling en duplicatie

Verzending van financiële bestanden vereist controles die voorkomen dat dezelfde geldige instructie herhaaldelijk wordt ingediend.

Een passend ontworpen architectuur dient daarom unieke transactie-identificatiecodes en passende controles te bevatten, zoals:

• unieke bericht-ID's;
• unieke transactie-ID's;
• tijdstempels;
• volgnummers;
• bestandsidentificatiecodes;
• detectie van dubbele berichten;
• idempotentiecontroles;
• registers van de verwerkingsstatus; en
• afstemming met eerder verwerkte instructies.

De ontvangende instelling dient dubbele instructies af te wijzen, in quarantaine te plaatsen of te onderzoeken overeenkomstig de overeengekomen operationele procedure.

10. Bestandsvalidatie

Succesvolle ontvangst van een bestand dient validatie te initiëren, niet automatische afwikkeling.

Een beveiligde verwerkingsomgeving kan het pakket onderwerpen aan meerdere opeenvolgende controles:

Fase 1 – Transportvalidatie

Bevestiging dat het pakket via een geautoriseerd kanaal is aangekomen.

Fase 2 – Endpointauthenticatie

Bevestiging van het verzendende systeem en de institutionele legitimatiegegevens.

Fase 3 – Controles op malware en bestandsbeveiliging

Inspectie van het archief en de daarin opgenomen bestanden vóór opname in de betalingsinfrastructuur.

Fase 4 – Cryptografische verificatie

Validatie van hashes, handtekeningen en certificaten.

Fase 5 – Structurele validatie

Bevestiging dat de bestanden voldoen aan het overeengekomen schema, de naamgevingsconventies, de tekencodering en de gegevensspecificatie.

Fase 6 – Semantische validatie

Bevestiging dat de verplichte betalingsvelden aanwezig en onderling consistent zijn.

Fase 7 – Transactievalidatie

Validatie van valuta, bedrag, rekeningen, routeringsinformatie, transactiereferenties en afwikkelingsinstructies.

Fase 8 – Compliancevalidatie

AML-, sanctie-, KYC/KYB-, transactiemonitoring- en andere toepasselijke controles.

Fase 9 – Validatie van de afwikkeling

Bevestiging dat er daadwerkelijk een mechanisme bestaat waarmee de overeenkomstige financiële waarde kan worden afgewikkeld.

Pas nadat deze controles zijn voltooid, dient een instructie te worden uitgevoerd overeenkomstig de toepasselijke procedures van de ontvangende instelling.

11. Bevestiging van ontvangst is geen afwikkeling

Een IP ZIP-omgeving kan meerdere technische bevestigingen genereren.

Bijvoorbeeld:

ACK – Bestand ontvangen

Hiermee wordt uitsluitend vastgesteld dat het ontvangende eindpunt het pakket heeft verkregen.

ACK – Bestand geauthenticeerd

Dit toont aan dat de authenticatiecontroles met succes zijn voltooid.

ACK – Bestand gevalideerd

Hiermee wordt vastgesteld dat het pakket voldeed aan de toepasselijke structurele of technische validatie.

ACK – Instructie aanvaard

Hiermee kan worden vastgesteld dat de betalingsopdracht in de verwerkingsstroom van de ontvangende instelling is opgenomen.

Geen van deze situaties betekent noodzakelijkerwijs:

AFGEWIKKELD

Voor de afwikkeling is een afzonderlijke financiële gebeurtenis vereist.

Het onderscheid is vergelijkbaar met dat in de conventionele financiële berichtgeving, waarbij de succesvolle aflevering en acceptatie van een betaalbericht moet worden onderscheiden van de definitieve afwikkeling van de onderliggende geldelijke verplichting.

12. Afwikkeling van de onderliggende transactie

Zodra een IP ZIP-betalingsinstructie is geauthenticeerd, gevalideerd, aanvaard en geautoriseerd, moet de onderliggende geldwaarde worden afgewikkeld via een geschikte financiële infrastructuur.

Afhankelijk van de betrokken valuta, instellingen en jurisdicties kan de afwikkeling plaatsvinden via:

• correspondentbankieren;
• Nostro-/Vostrorekeningen;
• rekeningen bij centrale banken;
• RTGS-infrastructuur;
• erkende clearingsystemen;
• binnenlandse betalingssystemen;
• infrastructuren voor instant betalingen;
• correspondentafwikkelingsbanken; of
• een andere juridisch en operationeel erkende afwikkelingsregeling.

14. Beveiligingsbeginsel

IFB hanteert een fundamenteel onderscheid ten aanzien van alle alternatieve overdrachtsmethoden:

Beveiligde transmissie bewijst dat gegevens veilig kunnen worden verzonden. Zij bewijst niet dat geld kan worden afgewikkeld.

• Versleuteling bewijst geen middelen.
• Een digitale handtekening bewijst geen middelen.
• Een serversaldo vormt geen bewijs van middelen.
• Een transactiebestand is geen bewijs van middelen.
• Succesvolle bestandsverwerking is geen bewijs van middelen.
• Een technische ontvangstbevestiging vormt geen bewijs van afwikkeling.

De doorslaggevende financiële vraag blijft of de initiërende instelling over geverifieerde liquiditeit en een operationeel afwikkelingstraject beschikt waarmee de overeenkomstige monetaire waarde via erkende bankinfrastructuur kan worden geleverd.

15. IFB-acceptatiekader

IFB kan IP-ZIP-transmissies uitsluitend overwegen voor goedgekeurde institutionele tegenpartijen en aanvaarde cliënten, na een naar tevredenheid afgeronde technische, juridische en compliancebeoordeling.

Voordat de productieverbinding tot stand wordt gebracht, kan IFB verificatie verlangen van:

• de initiërende instelling;
• institutionele bevoegdheid om de transactie door te geven;
• uiteindelijk belanghebbenden en transactiepartijen;
• herkomst en legitimiteit van de middelen;
• de onderliggende economische doelstelling;
• verzend- en ontvangstinfrastructuur;
• eigendom van het eindpunt;
• IP- en netwerkarchitectuur;
• authenticatiemethodologie;
• certificaten en cryptografische referenties;
• versleutelingsstandaarden;
• bestandsformaat en schema;
• structuur van betaalberichten;
• methodiek voor de identificatie van transacties;
• bevestigingsprotocol;
• controles op duplicaten en replay;
• afhandeling van uitzonderingen;
• afstemmingsprocedures;
• correspondentrelaties;
• afwikkelrekeningen;
• liquiditeitsregelingen; en
• het uiteindelijke afwikkelingstraject.

Technische interoperabiliteit alleen is onvoldoende.

IFB beschouwt de succesvolle verzending van een IP ZIP-pakket niet als ontvangst van middelen. De transactie is pas financieel voltooid wanneer de overeenkomstige waarde met succes is afgewikkeld via de overeengekomen bancaire of afwikkelingsinfrastructuur en de afwikkeling onafhankelijk kan worden gereconcilieerd.

Fundamenteel beginsel

IP ZIP is de beveiligde overdracht van een instructie. Afwikkeling is de overdracht van de bijbehorende financiële waarde.

De twee processen kunnen deel uitmaken van dezelfde transactieworkflow, maar zijn niet dezelfde gebeurtenis.

In de terminologie van het institutionele bankwezen:

Berichtverzending → authenticatie → validatie → aanvaarding → uitvoering → afwikkeling → reconciliatie

Pas na voltooiing van het toepasselijke afwikkelingsproces staat vast dat het geldelijke deel van de transactie is voltooid.

Terminologie die samenhangt met alternatieve of verouderde overdrachtsmethoden dient te worden uitgelegd in de context van de bankinfrastructuur. Dergelijke termen kunnen communicatiekanalen, interne verwerkingsmethoden of historische praktijken beschrijven, maar zij vervangen niet het vereiste van gereguleerde instellingen, erkende betalingssystemen en formele afwikkelingsprocedures.

Elke overdracht, ongeacht de gehanteerde terminologie, dient uiteindelijk te worden verwerkt, gecleard en gereconcilieerd binnen het bestaande financiële stelsel.

Indien u meer wilt weten over het overmaken van middelen of activa naar uw rekeningen bij ons, neemt u dan contact op met Marie Mayer.