SWIFT

SWIFT-overboekingen en communicatie met MT- en MX-berichten

SWIFT (Society for Worldwide Interbank Financial Telecommunication) is een beveiligd berichtennetwerk waarmee financiële instellingen, zoals banken, gestandaardiseerde berichten over financiële transacties kunnen verzenden en ontvangen, zoals betalingsopdrachten en bevestigingen. SWIFT houdt geen rekeningen aan en draagt geen gelden over; het biedt uitsluitend een beveiligd en betrouwbaar platform voor de uitwisseling van informatie.

Reguliere SWIFT-overboekingen maken gebruik van een reeks gestandaardiseerde berichttypen, bekend als MT-berichten (Message Type). Deze berichten hebben vooraf gedefinieerde formaten en velden, zodat financiële instellingen de erin opgenomen informatie eenvoudig kunnen begrijpen en verwerken.

MX-berichten (ISO 20022) vormen een nieuwere standaard voor financiële berichtgeving op basis van XML (eXtensible Markup Language). Zij bieden een rijker en beter gestructureerd formaat, waardoor gegevensuitwisseling wordt verbeterd en straight-through processing beter mogelijk is. MX-berichten vervangen geleidelijk MT-berichten binnen het SWIFT-netwerk, met als doel betere interoperabiliteit en gegevensverwerking.

Hoewel traditionele SWIFT-overboekingen al tientallen jaren de ruggengraat van internationale betalingen vormen, kennen zij enkele beperkingen, waaronder beperkte transparantie, tragere verwerkingstijden en ongestructureerde gegevens.

Swift 103+ STP (Straight Through Processing)

Swift 103+ STP was het verouderde MT-formaat dat was geoptimaliseerd voor Straight Through Processing (STP); sinds het einde van de coëxistentieperiode is die rol overgenomen door de STP-gebruiksrichtlijn voor pacs.008. STP maakt het mogelijk het gehele betalingsproces, van initiatie tot definitieve afwikkeling, elektronisch en zonder handmatige tussenkomst uit te voeren.

Aanvullende kenmerken:

1. Gestandaardiseerd formaat: Strikte naleving van een gestandaardiseerd formaat is vereist, waardoor fouten en vertragingen worden beperkt.
2. Geautomatiseerde verwerking: Transacties worden automatisch verwerkt, wat zorgt voor een snellere en efficiëntere afhandeling.
3. Minder handmatige tussenkomst: De noodzaak van handmatige invoer en verificatie wordt beperkt, waardoor het risico op fouten en vertragingen afneemt.
4. Snellere afwikkeling: Transacties worden sneller afgewikkeld dan met traditionele methoden.

Aandachtspunten voor STP:

1. Nauwkeurige gegevensinvoer: Gegevens moeten nauwkeurig worden ingevoerd om vertragingen of afwijzingen te voorkomen.
2. Naleving van de formatvereisten: Banken moeten ervoor zorgen dat de formatvereisten van 103+ STP strikt worden nageleefd.
3. Software en systemen: Banken dienen over passende software en systemen te beschikken om STP doeltreffend te kunnen verwerken

Het is essentieel om onderscheid te maken tussen berichtenverkeer en afwikkeling. SWIFT verzendt gestructureerde financiële berichten tussen instellingen, maar verplaatst zelf geen gelden en houdt zelf geen saldi aan. Een SWIFT-bevestiging, waaronder een pacs.008-bericht, is slechts geldig wanneer deze overeenkomt met een daadwerkelijke transactie die is verwerkt en afgestemd binnen de banksystemen van de deelnemende instellingen.

Een op zichzelf staand SWIFT-document, schermafbeelding of bericht dat zonder institutionele verificatie wordt overgelegd, mag niet worden beschouwd als bewijs van voltooide afwikkeling.

SWIFT gpi-overboekingen.

SWIFT gpi (Global Payments Innovation):

SWIFT gpi, in 2017 gelanceerd, is een initiatief dat de beperkingen van traditionele SWIFT-overboekingen wil wegnemen door de snelheid, transparantie en traceerbaarheid van grensoverschrijdende betalingen te verbeteren. SWIFT gpi maakt gebruik van de bestaande MT- en MX-berichtformaten om betalingsdiensten te verbeteren. Belangrijke kenmerken van SWIFT gpi zijn onder meer:

• Snellere betalingen: gpi vereenvoudigt processen en stelt strengere service level agreements (SLA's) tussen banken vast, wat leidt tot kortere transactietijden, vaak binnen enkele minuten of seconden.
• Betalingstracking: De gpi Tracker maakt realtimetracking van transacties mogelijk, wat de transparantie vergroot en handmatige onderzoeken beperkt.
• Transparantie over tarieven: Banken kunnen cliënten vooraf informatie verstrekken over transactiekosten, waardoor beter onderbouwde beslissingen mogelijk zijn.
• Rijkere gegevens: gpi ondersteunt een meer gedetailleerde en gestructureerde uitwisseling van informatie, wat een betere reconciliatie en naleving van regelgeving mogelijk maakt.

SWIFT gpi verhelpt de beperkingen van traditionele SWIFT-overboekingen door grensoverschrijdende betalingen te verbeteren met end-to-end-tracking, snellere verwerking en rijkere gegevens.

Kernparameters voor deelnemers die geen SWIFT gpi gebruiken

Wanneer een deelnemer die niet op SWIFT gpi is aangesloten (bijvoorbeeld een bank of financiële instelling die niet rechtstreeks bij gpi is ingeschreven) een betalingsinstructie verzendt naar een gpi-deelnemende bank, kan de gpi-bank deze omzetten naar de vereiste SWIFT-berichtformaten (pacs.008 voor klantkredietoverschrijvingen, pacs.009 COV voor coveroverschrijvingen en pacs.009 voor kredietoverschrijvingen tussen financiële instellingen). Deze omzetting maakt verwerking en tracking binnen het gpi-netwerk mogelijk, mits de instructie voldoende gegevens bevat om de verplichte velden in te vullen en te voldoen aan de gpi-regels, zoals end-to-end-traceerbaarheid.

Niet-gpi-deelnemers verstrekken deze parameters doorgaans via nationale betalingsschema's, API's of verouderde formaten, en de gpi-bank verzorgt de gpi-specifieke toevoegingen (bijvoorbeeld het genereren van een UETR indien deze niet is aangeleverd, hoewel het doorgeven ervan voor niet-gpi-entiteiten optioneel is). De exacte vereisten kunnen per rechtsgebied, valuta en bilaterale afspraak verschillen, maar de kernparameters zijn afgeleid van de CBPR+-richtlijnen (Cross-Border Payments and Reporting Plus) en de ISO 20022-normen. Sinds het einde van de coëxistentieperiode op 22 november 2025 worden grensoverschrijdende betalingsopdrachten uitgewisseld in ISO 20022-formaat; verwijzingen naar verouderde MT-velden hieronder dienen uitsluitend ter oriëntatie.
1. Identificatie van partijen (gegevens van debiteur en crediteur)
Hiermee worden de opdrachtgever en de begunstigde geïdentificeerd, zodat wordt voldaan aan Aanbeveling 16 van de FATF inzake de travel rule.

• Debiteur/opdrachtgevende klant: volledige naam, gestructureerd adres (straat, plaats, postcode, land) en rekeningidentificatie (bijv. IBAN of rekeningnummer). In het voormalige MT 103/MT 202 COV komt dit overeen met veld 50a; voor pacs.008/pacs.009 met <Dbtr> en <DbtrAcct>.
• Crediteur/begunstigde klant: Volledige naam, gestructureerd adres en rekeningidentificatie. Komt overeen met veld 59a in het voormalige MT 103/MT 202 COV; <Cdtr> en <CdtrAcct> in pacs.008/pacs.009.
• Uiteindelijke debiteur/crediteur (indien van toepassing): Indien deze afwijkt van de primaire partijen, vermeld dan hun gegevens voor meer transparantie (optioneel, maar aanbevolen voor gpi-tracking). Komt overeen met <UltmtDbtr>/<UltmtCdtr> in pacs.008/pacs.009.

Waarom vereist: Maakt juiste routering en regelgevende controles mogelijk; onvolledige gegevens kunnen leiden tot afwijzingen of vertragingen.

2. Informatie over agenten en routering
Specificeert de financiële instellingen die in de keten betrokken zijn.

• Debtor Agent: BIC (Bank Identifier Code) of een andere identificatiecode van de verzendende bank. Komt overeen met veld 52a in het voormalige MT 103; <DbtrAgt> in pacs.008/pacs.009.
• Creditor Agent: BIC van de ontvangende bank. Komt overeen met veld 57a in de voormalige MT 103/MT 202 COV; <CdtrAgt> in pacs.008/pacs.009.
• Tussenliggende banken (indien bekend): BIC's van eventuele correspondenten (maximaal 3 niveaus). Komt overeen met veld 56a in de voormalige MT; <IntrmyAgt1-3> in pacs.008/pacs.009.
• Instructing/Instructed Agents: BIC's van de onmiddellijke afzender/ontvanger in de keten. Optioneel, maar behulpzaam bij de seriële methode en de coverbetalingsmethode.
• Eerdere opdrachtgevende agenten (indien van toepassing): Bij ketens met meerdere schakels maximaal 3 voorgaande agenten.

Waarom vereist: Waarborgt de juiste routering via tussenpersonen; gebruik BICFI in plaats van namen voor nauwkeurigheid in pacs.009 COV.

3. Transactiegegevens
Kernelementen van de financiële afwikkeling.

• Bedrag en valuta: Interbancair afwikkelingsbedrag en ISO 4217-valutacode (bijv. USD, EUR). Komt overeen met veld 32A in de voormalige MT 103/MT 202 COV; <IntrBkSttlmAmt> in pacs.008/pacs.009.
• Opgedragen bedrag (indien afwijkend): Oorspronkelijk bedrag vóór inhoudingen.
• Interbancaire afwikkelingsdatum: Valutadatum voor de afwikkeling. Komt overeen met een deel van veld 32A in MT; <IntrBkSttlmDt> in pacs.008/pacs.009.
• Afwikkelingsmethode: Geef aan of via RTGS (CLRG), cover (COVE) of agent (INDA/INGA). Geen direct MT-equivalent, maar impliciet aanwezig.

Waarom vereist: Bepaalt de waardeoverdracht; verplicht voor alle formaten.

4. Referentie- en trackingidentificatoren
Voor de traceerbaarheid, met name in gpi.

• End-to-end-identificatie: een referentie die de volledige keten koppelt (bijv. factuur- of transactie-ID). <EndToEndId> in pacs.008/pacs.009.
• Instructie-identificatie: referentie van de afzender (in MT beperkt tot 16 tekens). Komt overeen met veld 20 in de voormalige MT; <InstrId> in pacs.008/pacs.009.
• Unique End-to-End Transaction Reference (UETR): Een UUID voor end-to-end tracking. Verplicht in pacs.008/pacs.009 en, in de voormalige MT103/MT202, in veld 121; indien een initiërend kanaal deze niet aanlevert, genereert de eerste Swift-bank in de keten de UETR.
• Transactie-identificatie: Aanvullende interne referentie.

Waarom vereist: Maakt gpi-tracking en -koppeling mogelijk (bijv. pacs.008 aan pacs.009 COV); de UETR is essentieel voor universele bevestigingen.

5. Doel- en dienstinformatie
Classificeert het type betaling.

• Doelcodes en categoriedoelcodes (Purpose en Category Purpose): ISO-codes (bijv. SALA voor salaris) die de aard van de transactie aangeven. Vereist in bepaalde corridors; <Purp> en <CtgyPurp> in pacs.008.
• Servicelevelcode: Geeft de gpi-dienst aan (bijv. G001 voor een gpi customer credit transfer); banken zonder gpi dienen geen gpi-specifieke codes op te nemen tenzij overeengekomen. Komt overeen met veld 23E in MT; <SvcLvl> in pacs.008/pacs.009.
• Local Instrument Code: Voor specifieke regelingen (bijv. intragroepsoverboekingen).

Waarom vereist: Waarborgt naleving van de regelgeving en verwerkingsprioriteit; na de ISO-migratie in toenemende mate verplicht.

6. Overmaking en aanvullende instructies

• Betalingskenmerk: Ongestructureerd (maximaal 140 tekens) of gestructureerd (bijv. factuurgegevens). Komt overeen met veld 70 in de voormalige MT 103; <RmtInf> in pacs.008/pacs.009.
• Instructies voor betrokken banken (agents): Bijvoorbeeld /REC/ voor de ontvanger, /ACC/ voor de rekening, of telefonische instructies (PHOB). Komt overeen met veld 72 in de voormalige MT; <InstrForNxtAgt>/<InstrForCdtrAgt> in pacs.008/pacs.009.
• Indicatoren voor afwikkelingstijd: Gevraagde tijdstippen (bijv. CLSTm voor CLS-tijd).

Waarom vereist: Biedt context en verwerkingsinstructies; essentieel voor dekkingsmethoden in pacs.009 COV.

7. Regelgevende en compliancegegevens

• Regelgevende rapportage: Codes of gegevens (bijv. fiscaal identificatienummer, rapportage-indicator zoals CRED/DEB). Correspondeert met veld 77B in MT; <RgltryRptg> in pacs.008/pacs.009.
• Retourredencodes (indien van toepassing bij retourbetalingen): Bijv. AC04 voor een opgeheven rekening, in pacs.004 gekoppeld aan oorspronkelijke berichten.

Waarom vereist: Voldoet aan de AML/KYC- en rapportageverplichtingen; verplicht in gereguleerde corridors.

Als beste praktijk geldt dat deelnemers die geen gpi gebruiken, hun gegevens zodanig dienen te structureren dat afkapping tijdens MT-naar-MX-conversies wordt voorkomen, en voor specifieke behoeften de gpi-lidbank dienen te raadplegen. Indien de betaling dekkingsmethoden omvat, moeten de onderliggende klantgegevens in alle berichten overeenkomen (bijvoorbeeld van pacs.008 naar pacs.009 COV).

Betalingsberichten in SWIFT gpi

In het SWIFT gpi-kader (Global Payments Innovation) worden de oorspronkelijke betaalberichten (bijv. pacs.008 voor cliëntoverschrijvingen of pacs.009 COV voor coveroverschrijvingen) na verzending als onveranderlijk beschouwd. Ontvangende banken kunnen de inhoud van deze berichten niet rechtstreeks wijzigen, aangezien SWIFT-berichten zijn ontworpen om de integriteit en controleerbaarheid gedurende de hele betaalketen te waarborgen. Wijzigingen, correcties of annuleringen worden in plaats daarvan afgehandeld via afzonderlijke vervolgberichten, statusupdates via de gpi Tracker of specifieke diensten zoals gSRP (gpi Stop and Recall Payment). Dit waarborgt end-to-end traceerbaarheid aan de hand van de Unique End-to-End Transaction Reference (UETR).

Ontvangende banken (doorgaans optredend als crediteursagent of tussenpersoon) kunnen echter reageren op wijzigingsverzoeken van de afzender of handelingen verrichten die feitelijk leiden tot wijzigingen in de uitkomst van de betaling (bijv. terugboekingen of blokkeringen). Zij kunnen onder bepaalde voorwaarden ook de afzender verzoeken om verduidelijking of wijziging. Deze processen worden beheerst door de rulebooks van SWIFT, de marktpraktijkrichtlijnen (bijv. van de Payments Market Practice Group – PMPG) en wettelijke vereisten, waarbij automatisering, transparantie en fraudepreventie voorop staan.

Voorwaarden waaronder ontvangende banken om wijzigingen mogen verzoeken of wijzigingen mogen faciliteren
Ontvangende banken kunnen om wijzigingen verzoeken (bijv. correcties van gegevens) of handelingen verrichten die impliceren dat een wijziging nodig is wanneer de oorspronkelijke betaling niet conform de instructie kan worden verwerkt. Dit gebeurt doorgaans via navraagberichten (bijv. MT 195/199) of via antwoorden op door de afzender geïnitieerde verzoeken. De belangrijkste voorwaarden zijn:

• Fouten in betalingsgegevens: Bij onjuistheden zoals een onjuist rekeningnummer van de begunstigde (bijv. opgeheven rekening – code AC04), een verkeerde valuta (code CURR), een onjuiste routering via de agent (code AGNT) of technische problemen (code TECH), kan de ontvangende bank de betaling in de wacht zetten en de afzender verzoeken gecorrigeerde gegevens te verstrekken of een nieuwe betaling te verzenden. Zo wordt een regelrechte afwijzing voorkomen en blijft oplossing mogelijk.
• Onmogelijkheid om de betaling te verwerken: Onder code CUTA (Cancel Upon Unable to Apply) kan de ontvangende bank, indien de betaling niet kan worden bijgeschreven wegens onjuistheden (bijv. afwijkingen in naam of rekeningnummer of onvoldoende gegevens), de verzendende partij verzoeken om details voor annulering of wijziging om de situatie te herstellen.
• Vermoedelijke fraude of ongeautoriseerde transacties: Bij fraude (code FRAD) kan de ontvangende bank zelfstandig problemen vaststellen en een terugboeking van de middelen initiëren zonder voorafgaand verzoek van de afzender. Zij kan ook reageren op terugroepverzoeken van de afzender door de middelen te blokkeren en een schadeloosstelling (code INDM) te verzoeken indien de middelen reeds zijn bijgeschreven, om het risico te beperken voordat zij worden teruggeboekt.
• Dubbele of onverschuldigde betalingen: Codes zoals DUPL (dubbele betaling) of UPAY (onverschuldigde betaling) stellen de ontvangende bank in staat de transactie te markeren en om annulering te verzoeken indien deze foutief of ongerechtvaardigd is.
• Regelgevende of compliancekwesties: Indien de betaling in strijd is met lokale wetgeving, sancties of AML-vereisten (code LEGL), kan de ontvangende bank de betaling afwijzen of aanhouden en de afzender om aanvullende documentatie of wijzigingen verzoeken.
• Beslissingen van de klant of begunstigde: Indien de begunstigde de betaling weigert (code CUST of NOAS – geen antwoord van de begunstigde), kan de ontvangende bank de betaling retourneren en de afzender op de hoogte stellen, waarbij mogelijk bevestiging van wijzigingen wordt gevraagd.
• Openstaande afhandelingen: Bij openstaande gevallen (code PDCR), zoals het wachten op debiteringsmachtiging (RQDA) of op antwoord van de volgende agent (PTNA), kan de ontvangende bank de betaling vasthouden en verdere instructies of wijzigingen opvragen om door te kunnen gaan.

In alle gevallen moeten verzoeken zijn gestructureerd voor automatisering (bijv. met vermelding van UETR, oorspronkelijke referenties zoals veld 20/32A/50/59 en specifieke codes in veld 79 van berichten) ter ondersteuning van straight-through processing. Er kunnen bilaterale vrijwaringsovereenkomsten vereist zijn indien middelen worden bijgeschreven, en de ontvangende bank is niet verplicht verzoeken te accepteren, maar moet dringende verzoeken (bijv. in verband met fraude) met voorrang behandelen.

Betrokken processen

• Reactie op door de afzender geïnitieerde recalls: De afzender (debiteurbank) initieert een recall doorgaans via MT 192/292 (of ISO 20022-equivalenten zoals camt.056) via de gSRP-dienst, serieel of rechtstreeks verzonden aan de ontvangende bank. De ontvangende bank dient onmiddellijk de ontvangst te bevestigen en te antwoorden met MT 196/296 (of MT 199/299 indien gestructureerd), met codes zoals CNCL (geannuleerd), RJCR (afgewezen met opgave van reden) of PDCR (in behandeling). Indien de recall wordt geaccepteerd, worden de gelden teruggestort via pacs.004 (Payment Return).
• Zelfstandige handelingen van ontvangende banken: Indien intern fraude wordt vastgesteld, kan de ontvangende bank de middelen retourneren via pacs.004 met gestructureerde gegevens, waarbij via de Tracker een melding wordt gedaan voor statusupdates in real time.
• Verzoeken om wijziging/verduidelijking: Ontvangende banken gebruiken navraagberichten (bijv. MT 195/295) om wijzigingen te verzoeken, zoals aanvullende gegevens. Dit komt vaak voor bij betalingen die in de wacht staan.
• Trackerintegratie: Alle acties werken de gpi Tracker in real time bij, toegankelijk via API's of een grafische gebruikersinterface, zodat alle partijen inzicht hebben. gpi-leden moeten voldoen aan de verplichte rulebooks voor gCCT (Customer Credit Transfer), gCOV (Cover) en gSRP.
• Beperkingen en succesfactoren: Wijzigingen worden niet gegarandeerd; het succes hangt af van de fase van de betaling (eenvoudiger vóór creditering), de medewerking van de begunstigde en de jurisdictie. Indien reeds gecrediteerd, vereisen retourbetalingen de toestemming van de begunstigde of een vrijwaring. Regelgeving gaat altijd boven richtlijnen.

Deze praktijken gelden primair voor gpi-leden, maar banken die geen gpi-lid zijn kunnen via gateways deelnemen. Raadpleeg voor de meest actuele details de officiële regelboeken van SWIFT, aangezien processen zich ontwikkelen (bijvoorbeeld met de migratie naar ISO 20022).

Scheiding van berichtenverkeer en afwikkeling in SWIFT gpi

SWIFT gpi verwerkt primair betalingsinstructies en tracking via berichtenverkeer (bijv. ISO 20022-formaten zoals pacs.008 voor klantbetalingen, pacs.009 voor financiële overboekingen, of de oudere MT103/MT202), maar de daadwerkelijke geldstroom vindt afzonderlijk plaats op het niveau van de afwikkeling. De afwikkeling geschiedt doorgaans via correspondentbankrelaties (nostro-/vostrorekeningen), bilaterale verrekening of clearing- en afwikkelingsmechanismen (CSM's) zoals Real-Time Gross Settlement-systemen (RTGS) (bijv. T2, voorheen TARGET2, in Europa, Fedwire in de VS of CHAPS in het VK). De gpi Tracker biedt realtime inzicht in de berichtstatus, maar de geldoverdracht berust op deze onderliggende systemen.

De coëxistentieperiode voor grensoverschrijdende betalingsinstructies is op 22 november 2025 geëindigd: betalingsinstructies zoals MT103 en MT202 zijn vervangen door ISO 20022 (MX)-berichten zoals pacs.008 en pacs.009, terwijl andere MT-categorieën op latere data worden uitgefaseerd. Hieronder wordt toegelicht hoe retourneringen en het vrijgeven van blokkeringen plaatsvinden op het niveau van rekening, clearing en afwikkeling.

Hoe geld wordt teruggestort op rekening-, clearing- en afwikkelingsniveau
Terugstortingen worden geïnitieerd na een succesvol terugroepverzoek (via gSRP – gpi Stop and Recall Payment-dienst) of na onafhankelijke detectie (bijv. fraude, fouten). De gSRP gebruikt camt.056 (Payment Cancellation Request) van de afzender, beantwoord met camt.029 (Resolution of Investigation). Zodra het verzoek is aanvaard, wordt de teruggave van middelen uitgevoerd via een nieuwe betalingsinstructie die de stroom omkeert, waarbij de rekening van de ontvangende bank wordt gedebiteerd en het bedrag via de keten wordt teruggeboekt. Dit is geen wijziging van het oorspronkelijke bericht, maar een afzonderlijke transactie.

Belangrijkste afwikkelingsmethoden en retourprocessen
Afwikkelingsmethoden bepalen hoe retourneringen plaatsvinden:

• CLRG (Clearing via Market Infrastructure): Afwikkeling via een RTGS of CSM (bijvoorbeeld via een centrale bank). Retourberichten gebruiken pacs.004 om de MI de opdracht te geven de rekening van de ontvangende agent te debiteren en die van de voorgaande agent te crediteren, vaak in realtime of op dezelfde dag.
• INGA (Instructing Agent Settles First): De afzender rekent de middelen af voordat het bericht wordt verzonden. Retourneringen via pacs.004 belasten de rekening van de instructed agent na de afwikkeling.
• INDA (Instructed Agent Settles on Receipt): De ontvanger wikkelt de betaling af bij ontvangst van het bericht. Indien niet afgewikkeld, afwijzen via pacs.002 (er worden geen middelen overgemaakt); indien afgewikkeld, retourneren via pacs.004.
• COVE (Cover Method): Wordt gebruikt voor betalingen met een hoge waarde met een afzonderlijke dekkingsoverboeking (pacs.009 COV). Retourbetalingen volgen de omgekeerde keten: pacs.004 van de bank van de begunstigde terug naar de tussenliggende banken, met dienovereenkomstige debitering en creditering van correspondentrekeningen.

Stapsgewijs retourproces op afwikkelingsniveau

1. Initiatie en acceptatie: De afzender verzoekt om terugroeping (bijv. via camt.056 met UETR). De ontvanger antwoordt (camt.029) en accepteert indien de middelen beschikbaar zijn of nog niet zijn bijgeschreven bij de begunstigde (eenvoudiger vóór bijschrijving). Indien reeds bijgeschreven, kan toestemming van de begunstigde of een vrijwaring vereist zijn.

2. Instructie tot terugboeking van middelen: de ontvanger verstuurt een pacs.004 (Payment Return) of een traditionele MT 103/MT 202 met retourcodes (bijv. RETN). Dit bericht bevat:

• Oorspronkelijke referenties (UETR, End-to-End ID, Instruction ID).
• Omgekeerde rollen: de oorspronkelijke crediteur wordt debiteur; de agent van de oorspronkelijke debiteur wordt crediteur.
• Afwikkelingsgegevens: oorspronkelijk interbancair afwikkelingsbedrag/oorspronkelijke afwikkelingsdatum, wisselkoers (indien valuta-omrekening plaatsvindt), kosten (indien ingehouden).
• Retourredencode (bijv. AC04 voor opgeheven rekening, FRAD voor fraude).
• Veld Settlement Account (indien aanwezig in het oorspronkelijke bericht) om de te crediteren rekening aan te geven.

3. Uitvoering van de afwikkeling:

• De pacs.004 leidt tot een debitering van de nostro-/vostrorekening van de ontvangende bank (aangehouden bij de voorafgaande agent of MI).
• De middelen worden hop voor hop door de keten teruggecrediteerd, met dezelfde afwikkelingsmethode (bijv. RTGS-overboeking in CLRG).
• Bij gedeeltelijke teruggave vermeldt u „PART” in Aanvullende informatie, met het naar rato berekende bedrag.
• De tracker werkt de status (bijvoorbeeld "Returned") in realtime bij, zichtbaar via de API of de GUI.

4. Definitieve creditering: De rekening van de oorspronkelijke afzender wordt gecrediteerd, vaak na aftrek van kosten. Bij verwerking via een CSM is de afwikkeling atomair; bij bilaterale opzetten kan dit gepaard gaan met netting aan het einde van de dag.

5. Meldingen na retournering: Gebruik camt.053/054 (rekeningafschrift/debet-creditbericht) om de grootboekbijwerkingen te bevestigen. Geen nieuwe pacs.004 voor het "retourneren van een retour": gebruik daarvoor navraagberichten.
Retourneringen worden waar mogelijk geautomatiseerd, maar handmatig ingrijpen kan plaatsvinden om redenen van compliance of indien middelen zijn bevroren. Terugvordering is niet gegarandeerd; zij hangt er vooral van af hoe snel de terugroeping wordt verzonden en of de middelen reeds zijn bijgeschreven. Indien nog niet afgewikkeld (bijv. geweigerd vóór afwikkeling), worden geen middelen verplaatst: gebruik in dat geval pacs.002.

Hoe vastgehouden betalingen worden vrijgegeven (groen licht) op rekening-, clearing- en afwikkelingsniveau

Een hold ontstaat wanneer een betaling niet onmiddellijk kan worden verwerkt (bijvoorbeeld als gevolg van fouten, compliancecontroles of in afwachting van opheldering), waardoor zij in een status “in behandeling” blijft zonder te zijn afgewikkeld. Er worden geen gelden gedebiteerd of gecrediteerd totdat het probleem is opgelost. De gpi Tracker toont statussen zoals “On Hold” of “Pending” (bijvoorbeeld de code PDCR), en de oplossing verloopt via navraagberichten (MT 195/199 of camt.029).

Omstandigheden die tot een blokkering leiden

• Afwijkingen (bijv. discrepantie tussen rekening en naam – CUTA-code).
• Regelgevende controles (bijv. sancties – LEGL-code).
• In afwachting van reactie van de begunstigde (NOAS-code) of debetmachtiging (RQDA).
• Offlinetijden of batchverwerking bij de bank van de begunstigde.

Vrijgaveproces op afwikkelingsniveau
1. Melding van aanhouding: De ontvanger stuurt een pacs.002 (statusupdate) of MT 199 met een pendingcode en houdt de middelen aan op een tussenrekening/escrowrekening indien zij gedeeltelijk zijn afgewikkeld (bijv. bij coverbetalingen).
2. Oplossing: De afzender levert wijzigingen/verduidelijkingen aan (bijv. via een MT 195-antwoord of camt.029). Indien het probleem is opgelost, geeft de ontvanger groen licht door de oorspronkelijke instructie te verwerken.
3. Uitvoering van de afwikkeling:

• Het oorspronkelijke pacs.008/pacs.009 wordt vrijgegeven uit de wachtstand.
• De middelen worden afgewikkeld via de opgegeven methode: debitering van de rekening van de afzender, creditering van die van de ontvanger (bijv. via RTGS in CLRG), gevolgd door de definitieve creditering van de rekening van de begunstigde.
• De begunstigdenfase (ontvangende bank naar eindklant) is vaak de fase waarin vertragingen optreden, met name in markten met kapitaalbeperkingen of beperkte infrastructuur.
• De tracker wordt bijgewerkt naar “Gecrediteerd” of “Voltooid”, met bevestiging door pacs.002 (Payment Status Report).

4. Indien niet vrijgegeven: indien het geval onopgelost blijft (bijv. na een time-out), retourneer via pacs.004 zoals hierboven, of wijs af met pacs.002 (geen afwikkeling).

De gpi-regels vereisen waar mogelijk bijschrijving op dezelfde dag; Swift meldde in 2018 dat bijna 50% van de gpi-betalingen binnen 30 minuten en bijna 100% binnen 24 uur werd bijgeschreven. Factoren zoals kapitaalcontroles of de uren waarin banken offline zijn, kunnen de vertraging verlengen, maar gpi legt de nadruk op automatisering om die tot een minimum te beperken.

SwiftNet Instant

SwiftNet Instant. Dit is een realtime berichtenplatform met lage latentie dat 24/7 beschikbaar is en de beveiligde uitwisseling van directe betalingsstromen tussen Clearing and Settlement Mechanisms (CSM's) en hun deelnemers ondersteunt.

Klanten kunnen verbinding maken met SwiftNet Instant via hun bestaande Swift-connectiviteit en beveiligingsinfrastructuur, waaronder VPN-boxen, huurlijnen en hardwarebeveiligingsmodules. De integratie met de IT-omgeving van de bank wordt gerealiseerd via de Alliance Gateway Instant (AGI).

Alle partijen in de keten van directe betalingen kunnen gebruikmaken van AGI en SwiftNet Instant-berichtenverkeer. Toepassingen omvatten onder meer betalingsinitiatie vanuit een overlayservice, indirecte communicatie van leden met een sponsorlid, of een onderneming die een betalingsbevestiging ontvangt.

SWIFT Instant maakt verbinding met nationale instant-betalingssystemen om transacties in realtime te verwerken, zowel binnenlands als internationaal, op basis van de ISO 20022-standaard. Deze systemen vormen een voortdurende inspanning om betalingsprocessen in de financiële sector te moderniseren en te vereenvoudigen.

Automatische incasso via SWIFT

Een rechtstreekse incasso (direct debit) in het SWIFT-systeem is een betaalmethode waarmee bedrijven en particulieren in meerdere valuta's en in verschillende landen gelden kunnen incasseren van bankrekeningen van schuldenaren. In tegenstelling tot de SEPA-incasso, die specifiek is ontworpen voor het SEPA-gebied en beperkt is tot transacties in euro, heeft de rechtstreekse incasso in SWIFT een wereldwijd bereik en ondersteunt deze een breed scala aan valuta's.

Het initiëren van een automatische incasso binnen het SWIFT-systeem verloopt doorgaans als volgt:

1. Overeenkomst tussen schuldeiser en schuldenaar: De schuldeiser en de schuldenaar dienen over een reeds bestaande overeenkomst te beschikken, waarin de voorwaarden voor incassotransacties zijn vastgelegd. Deze overeenkomst kan tevens het instellen van een machtiging of autorisatie omvatten, waardoor de schuldeiser betalingen mag incasseren van de bankrekening van de schuldenaar.
2. Berichtenuitwisseling: De bank van de crediteur initieert de incasso door een SWIFT-bericht te sturen naar de bank van de debiteur – in ISO 20022 een pacs.003 (klantincasso) of pacs.010 (incasso tussen financiële instellingen), voorheen MT 104 of MT 204. Dit bericht bevat de gegevens van de transactie, zoals het bedrag, de valuta, de rekeninggegevens van de debiteur en alle overige benodigde informatie.
3. Verificatie en autorisatie: de bank van de debiteur verifieert de transactiegegevens, controleert of de middelen beschikbaar zijn op de rekening van de debiteur en bevestigt de autorisatie van de transactie. Als alles in orde is, gaat de bank van de debiteur over tot het debiteren van de middelen van de rekening van de debiteur.
4. Overdracht van middelen: De middelen worden afgewikkeld tussen de bank van de debiteur en de bank van de crediteur via correspondentrekeningen of een clearing- en afwikkelingssysteem.
5. Bevestiging: Na ontvangst van de gelden stuurt de bank van de crediteur een bevestiging aan de crediteur, waarin deze op de hoogte wordt gesteld van de geslaagde automatische incasso.

De voorwaarden voor het initiëren van een incassotransactie binnen het SWIFT-systeem zijn de volgende:

1. Bankrekeningen: Zowel de schuldeiser als de schuldenaar moet beschikken over bankrekeningen bij financiële instellingen die deel uitmaken van het SWIFT-netwerk.
2. Overeenkomst en machtiging: Er moet een bestaande overeenkomst en machtiging (mandaat) tussen de schuldeiser en de schuldenaar zijn om transacties via automatische incasso mogelijk te maken.
3. SWIFT-berichtformaten: De crediteur en diens bank moeten de juiste berichtformaten gebruiken: pain.008 om een incasso te initiëren, pacs.003 of pacs.010 tussen banken.
4. Bankkosten: De crediteur en de debiteur dienen zich bewust te zijn van eventuele kosten die aan incassotransacties binnen het SWIFT-systeem zijn verbonden, aangezien deze kosten kunnen verschillen naargelang de banken en landen.

RMA in interbancaire SWIFT-berichtgeving

In het bank- en financiewezen is veilige en efficiënte communicatie tussen banken essentieel. Hier speelt SWIFT (Society for Worldwide Interbank Financial Telecommunication) een cruciale rol: het verzorgt het merendeel van de internationale berichten tussen banken. Een essentieel onderdeel dat de veiligheid en selectiviteit van deze communicatie waarborgt, is de Relationship Management Application (RMA).

Wat is RMA?

Relationship Management Application (RMA) is een SWIFT-softwaretoepassing waarmee financiële instellingen kunnen bepalen welke tegenpartijen hun SWIFT-berichten mogen sturen en die ervoor zorgt dat communicatie via het SWIFT-netwerk beperkt blijft tot geauthenticeerde gebruikers. RMA vormt een fundamentele beveiligingslaag in het beheer van interbancaire communicatie, aangezien zij ongeautoriseerde berichten filtert en het risico op fraude verkleint.

Het belang van RMA

Voor banken die internationaal financieel actief zijn, zoals IFB, is het RMA-instrument onmisbaar. Het versterkt niet alleen de beveiligingsprotocollen, maar waarborgt ook de naleving van internationale bankregelgeving. Door te beheren welke instellingen hun berichten mogen sturen, kunnen banken ongeoorloofde informatieverzoeken en financiële instructies voorkomen en zo zowel hun eigen belangen als die van hun cliënten beschermen.

Hoe RMA werkt

Het RMA-proces omvat verschillende belangrijke stappen:

1. Totstandbrenging van RMA-relaties: voordat twee banken informatie via SWIFT kunnen uitwisselen, moeten zij onderling overeenkomen een RMA tot stand te brengen. Deze overeenkomst is te vergelijken met een digitale handdruk en brengt vertrouwen en instemming met het onderling communiceren tot uitdrukking.
2. Uitwisseling van sleutels: elke bank verzendt via de RMA-applicatie een RMA-autorisatie, die de tegenpartij aanvaardt. RMA heeft de eerdere bilaterale sleuteluitwisseling (BKE) vervangen; de berichten zelf worden geauthenticeerd via SWIFTNet PKI (Public Key Infrastructure).
3. Configuratie van RMA-instellingen: Elke bank gebruikt de RMA-tool om machtigingen te configureren en vast te leggen welke typen berichten van de andere bank worden geaccepteerd. Dit kan globaal worden ingedeeld of nauwkeurig worden afgestemd op specifieke berichttypen en subklassen.
4. Activering en monitoring: Zodra de RMA-instellingen zijn geconfigureerd en geactiveerd, kunnen banken inkomende berichten monitoren op naleving van de vastgestelde machtigingen. RMA biedt tevens instrumenten om machtigingen te wijzigen of in te trekken indien bedrijfsbehoeften of beveiligingsoverwegingen daartoe aanleiding geven.

Praktische toepassingen

Voor IFB, dat zich specialiseert in beleggings- en vermogensbeheer voor vermogende particulieren en zakelijke entiteiten, biedt RMA verschillende voordelen:

• Verbeterde beveiliging: Door het berichtenverkeer te beheersen kan IFB cliënttransacties en gevoelige informatie beveiligen tegen onbevoegde toegang.
• Operationele efficiëntie: Gestroomlijnde communicatie met vertrouwde entiteiten zorgt voor een snellere afhandeling van legitieme berichten, wat de reactietijden en de tevredenheid van cliënten verbetert.
• Naleving van regelgeving: RMA ondersteunt de naleving van internationale bankregelgeving, die strikte controle op de uitwisseling van informatie voorschrijft om financiële misdrijven zoals witwassen en fraude te voorkomen.

RMA en MT799. Banken kunnen een MT799 gebruiken om een RMA-relatie aan te vragen of te coördineren, mits het kanaal dit toelaat. De RMA-autorisatie zelf wordt verleend in het RMA-systeem; een MT799 alleen activeert geen enkele machtiging. Indien de voor MT799 vereiste RMA-autorisatie ontbreekt, kan deze niet worden omzeild door rechtstreeks een MT799 te verzenden. De inrichting wordt dan overeengekomen via de RMA-communicatiefunctie van de Relationship Management Portal van Swift, die bedoeld is voor afstemming met tegenpartijen voordat autorisaties worden uitgewisseld, of via een ander toegestaan kanaal. “RMA via MT799” kan dus de begeleidende bankcorrespondentie aanduiden; de technische RMA-autorisatie is een afzonderlijke stap.

Kortom

Voor IFB is een doeltreffende implementatie van RMA niet slechts een technische vereiste, maar een strategische troef in haar wereldwijde activiteiten. Zij versterkt de toewijding van de bank aan beveiliging en naleving van de regelgeving en verhoogt tegelijkertijd de efficiëntie van haar communicatienetwerken. Naarmate het internationale financiële landschap zich verder ontwikkelt, blijven instrumenten als RMA onmisbaar in het arsenaal van banken die zich inzetten voor de hoogste normen van operationele integriteit en cliëntenservice.

RMA's vormen de ruggengraat van veilige en selectieve interbancaire communicatie en waarborgen dat elk bericht dat via het SWIFT-netwerk wordt uitgewisseld voldoet aan de hoogste beveiligingsnormen en volledig is geauthenticeerd. Voor banken zoals IFB is inzicht in en beheer van RMA's van cruciaal belang om hun activiteiten te beveiligen en vertrouwen op te bouwen bij hun wereldwijde partners.

Swift Digital Blockchain Financial Instructions

In september 2025 maakte Swift bekend dat het, samen met meer dan 30 financiële instellingen, was begonnen met het ontwerpen en ontwikkelen van een gedeeld digitaal grootboek. Op 9 juli 2026 verklaarde Swift het grootboek gereed voor initieel gebruik, waarbij 17 banken zich voorbereiden op een pilot met live transacties in getokeniseerde deposito's: ANZ, BNP Paribas, BNY, Citi, DBS, First Abu Dhabi Bank, FirstRand, HSBC, Itaú Unibanco, Lloyds, Mashreq, MUFG, OCBC, Standard Chartered, UBS, UOB en Wells Fargo. De eerste toepassing richt zich op het mogelijk maken van grensoverschrijdende instructies tussen banken in realtime en 24/7 – een essentiële verbetering van de structuur van internationale transactieverwerking.

Het eerste conceptuele prototype is gebouwd met Consensys. Het grootboek is ontworpen als een veilig, onveranderlijk register in real time van financiële instructies tussen instellingen. Het zal transactieberichten vastleggen, in volgorde plaatsen en valideren, en daarbij operationele en compliance-regels afdwingen via smart contracts. Interoperabiliteit is een centraal beginsel: het grootboek zal aansluiten op zowel bestaande als opkomende infrastructuren, met behoud van de kenmerkende veerkracht, het vertrouwen en de naleving van regelgeving van Swift.

Zoals Swift-CEO Javier Pérez-Tasso toelichtte:
"De combinatie van een gedeeld grootboek met de bestaande berichtenuitwisseling, API's en ISO 20022 van Swift vormt een nog krachtiger geheel, waarin risico-, controle- en compliancevereisten vanaf het begin in de transactiestromen worden ingebed, terwijl interbancaire grensoverschrijdende instructies 24/7 in realtime mogelijk worden, met hetzelfde vertrouwen, dezelfde veiligheid, veerkracht, schaalbaarheid en operationele uitmuntendheid waarvoor Swift bekendstaat. Dit alles in lijn met de aanpak die wij altijd hebben gevolgd: verantwoorde innovatie."

Uitbreiding van de infrastructuur

Het gedeelde grootboek vormt een aanvulling op de bestaande netwerken van Swift; het vervangt deze niet. Het is bedoeld om de orkestratie en interoperabiliteit uit te breiden, zodat financiële instellingen sneller, met meer voorspelbaarheid en op werkelijk mondiale schaal instructies kunnen uitwisselen.

Tijdens Sibos benadrukte Pérez-Tasso deze tweesporenaanpak:
"Financiële infrastructuren moeten onverminderd gefocust blijven op de fundamenten van operationele excellentie, naleving van regelgeving en governance. En tegelijkertijd moeten ze zich voorbereiden op de toekomst. En bij Swift is onze aanpak om op twee parallelle sporen te innoveren."

Samenwerking binnen de sector

Financiële instellingen uit 16 landen waren vanaf het begin betrokken bij de vormgeving van het ontwerp, het bestuur en het ontwikkeltraject van het gedeelde grootboek. Deze gezamenlijke inspanning onderstreept een gedeeld inzicht: de bevordering van de mondiale infrastructuur voor interbancaire instructies vereist schaal en samenwerking.

Vooruitblik

Het gedeelde grootboek is een natuurlijke voortzetting van de eerdere proeven van Swift met digitale activa en maakt deel uit van een bredere inzet voor interoperabiliteit tussen zowel openbare als private netwerken. Hierdoor kunnen gereguleerde getokeniseerde waarde en traditionele instrumenten zich naadloos tussen systemen verplaatsen.

Pérez-Tasso vatte de visie samen:
“Dit is een krachtig platform voor de toekomst. En in de toekomst kan het nog transformerender worden.”

Veelgestelde vragen

Wat is het op blockchain gebaseerde gedeelde grootboek van Swift?
Een blockchaininfrastructuur die een gedeelde, realtime registratie van financiële instructies tussen instellingen biedt en daarmee continue, conforme grensoverschrijdende verwerking mogelijk maakt.

Voor wie is het bedoeld?
Banken en financiële instellingen die snellere, transparantere transactie-instructies moeten leveren en zich tegelijkertijd voorbereiden op de digitale toekomst.

Wat zijn de voordelen?

• Realtime inzicht in en volgordebepaling van instructies
• Geautomatiseerde compliance via smart contracts
• Interoperabiliteit tussen traditionele en digitale netwerken
• Veilige afwikkeling van gereguleerde getokeniseerde waardestromen

Hoe past dit binnen het platform van Swift?
Het breidt de vertrouwde infrastructuur van Swift uit door digitale instructiemogelijkheden te integreren, met behoud van veerkracht, beveiliging en compliance.

Wat is de eerste toepassing?
Realtime, 24/7 grensoverschrijdende interbancaire transactie-instructies.

Wie zijn betrokken?
Meer dan 30 financiële instellingen uit 16 landen hebben bijgedragen aan het ontwerp; 17 banken voeren een pilot uit met de eerste live transacties.

Wanneer is het beschikbaar?
Swift heeft het grootboek op 9 juli 2026 gereed verklaard voor initieel gebruik. De pilotbanken voeren de eerste live-transacties uit in een gecontroleerde go-livefase; de definitieve afwikkeling verloopt nog via bestaande systemen. De functionaliteit en beschikbaarheid worden daarna uitgebreid.

Wilt u meer weten over het overboeken van middelen via het correspondentbankstelsel? Neem dan contact op met ons Hoofd Correspondentbankieren, de heer Amri Elarisse.