Wat is SWIFT ** bekend ** SWIFT = wereldwijd netwerk voor gestandaardiseerde financiële berichten tussen banken en financiële instellingen. Geen geldtransport → alleen berichten (instructies). Kernconcept Bank A stuurt bericht → SWIFT netwerk → Bank B Bericht = instructie (bijv. betaling uitvoeren) Uitvoering gebeurt in achterliggende systemen (clearing/settlement) Structuur van een SWIFT bericht Header (routing, BIC codes) Body (transactiegegevens) Trailer (controle / security) Identificatie BIC (Bank Identifier Code) = unieke bankcode Voorbeeld: DEUTDEFF (Deutsche Bank Frankfurt) Twee hoofdstandaarden MT (Message Type, legacy, bijv. MT103) MX (ISO 20022, XML-gebaseerd, toekomststandaard) MT (legacy, vast formaat) ** bekemd ** MT103 — internationale klantbetaling Structuur (vereenvoudigd): :20:REFERENCE123 :32A:250418EUR1000,00 :50K:/123456789 JOHN DOE :59:/987654321 JANE DOE :71A:SHA Kenmerken: Vaste velden (:20:, :32A:, etc.) Tekstgebaseerd, niet XML MX (ISO 20022, XML) pacs.008 — equivalent van MT103 Structuur (vereenvoudigd): REF123 1000.00 JOHN DOE JANE DOE Kenmerken: XML-structuur Rijkere data, uitbreidbaar Nieuwe standaard (vervangt MT) Kernverschil: MT = compact, cryptisch MX = gestructureerd, leesbaar, toekomstvast Les 2 — End-to-end betalingsflow (wat jij moet testen) ** snap ik ** Stappen in de keten Initiatie: klant → bank A (payment order) Validatie: checks (saldo, compliance, format) Message creation: MT103 / pacs.008 Routing: via correspondent banks / SWIFT Ontvangst: bank B ontvangt bericht Clearing & settlement: geld wordt daadwerkelijk verrekend Booking: bedrag op rekening begunstigde Status/feedback: ACK/NACK of statusbericht terug Waar jij test (SIT/UAT relevant) Input → is order correct omgezet naar message Message → format, velden, mapping correct Routing → juiste BIC / pad Ontvangst → verwerking zonder fouten Settlement → juiste bedragen/valuta End state → juiste booking + status Kern: Test niet alleen het bericht, maar de volledige keten van input → verwerking → uitkomst. Les 3 — SIT vs UAT (kritisch onderscheid) **snap ik ** SIT (System Integration Testing) Doel: controleren dat systemen correct samenwerken Wat je test: Interfaces (bijv. payment engine ↔ SWIFT gateway) Message mapping (velden correct overgezet) Technische verwerking (geen crashes, juiste flow) Error handling (wat gebeurt bij fout bericht) Focus: technisch correct functioneren van de keten UAT (User Acceptance Testing) Doel: valideren dat oplossing voldoet aan business requirements Wat je test: Business scenario’s (betaling, annulering, uitzonderingen) Verwachte uitkomst (bedrag, valuta, datum, fees) Compliance/logica (regels correct toegepast) Acceptatie door business users + sign-off Focus: werkt het zoals de business het nodig heeft Kernverschil: SIT = “werkt het systeem technisch?” UAT = “werkt het voor de business correct?” Les 4 — Defect management (wat jij concreet doet) ** kan ik ** Defect lifecycle Detectie (in SIT/UAT) Logging (in tool zoals Jira) Classificatie: severity (impact) + priority (urgentie) Analyse (root cause: mapping, data, logic, interface) Fix (development) Retest (valideren oplossing) Closure (akkoord) Wat jij bewaakt Volledige en reproduceerbare defectbeschrijving (input, verwachte uitkomst, feitelijke uitkomst) Traceability naar requirement / test case Prioritering: business impact leidend Transparante statusrapportage (open, in progress, blocked, closed) Kern: Niet alleen bugs registreren, maar beslisbaar maken wat eerst opgelost moet worden richting go-live. Les 5 — Testcase design (hoe je testgevallen opstelt) ** ik ken de theorie ** Structuur van een testcase ID Requirement link Preconditions (startcondities) Input (data / actie) Expected result Actual result (tijdens run) Status (pass/fail) Ontwerpmethoden (relevant voor job) Equivalence partitioning → groepen input (bijv. geldige/ongeldige IBAN) Boundary value analysis → randen (bijv. bedrag = 0, max limiet) Positive / negative scenarios End-to-end scenario’s (volledige payment flow) Kern: Goede testcases zijn herhaalbaar, eenduidig en direct gekoppeld aan requirements. Les 6 — Traceability (controle op volledigheid) ** meer theorie , weet ik ** Wat is het Koppeling tussen: Requirements Testcases Defects Meestal vastgelegd in een traceability matrix (RTM) Doel Zekerstellen dat alle requirements getest zijn Impactanalyse bij wijzigingen Onderbouwing voor go-live / audit Wat jij doet Elke requirement → minimaal 1 testcase Elke defect → gelinkt aan testcase + requirement Gaps signaleren (requirement zonder test = risico) Kern: Zonder traceability geen bewijs dat je systeem volledig getest is. Les 7 — Go-live readiness (beslismoment) ++ snap ik , weet ik ** Wat bepaalt “ready” Alle kritische defects opgelost (severity 1/2 = 0 open) Testcoverage compleet (alle requirements getest) UAT sign-off door business Geen blockers in end-to-end flow Rapportage: status, risico’s, restpunten Jouw rol Objectief beeld geven (geen “gevoel”, maar data) Risico’s expliciet maken (wat kan nog misgaan) Beslissing faciliteren: go / no-go Stakeholders alignen (business + IT) Kern: Niet jij beslist, maar jij levert de feiten waarop de beslissing verantwoord genomen wordt. weer over de bank. Les 9 — Clearing vs Settlement (kritisch bankconcept) ** begrijp ik** Clearing Verwerken en matchen van betalingsinstructies Controle: klopt bedrag, tegenpartij, valuta Netto of bruto positie bepalen tussen banken Settlement Feitelijke geldverplaatsing tussen banken Via centrale systemen (bijv. centrale bank / clearing house) Finaliteit: transactie is onomkeerbaar Waarom dit belangrijk is voor jou SWIFT bericht ≠ geld Fouten kunnen zitten in: message correct, maar settlement fout of omgekeerd In UAT moet je valideren: input → bericht → clearing → settlement → booking klopt volledig Kern: Clearing = berekenen/verifiëren Settlement = daadwerkelijk afrekenen (geld beweegt) Les 10 — Correspondent banking (cross-border realiteit) ** kennis van ** Wat is het Banken hebben niet overal directe rekeningen → ze gebruiken correspondent banks (tussenbanken). Flow: Bank A → correspondent → (evt. meerdere) → Bank B Kernmechanisme Nostro account = jouw geld bij andere bank Vostro account = geld van andere bank bij jou Betaling loopt via deze rekeningen (liquiditeit) Waarom dit belangrijk is voor testen Routing moet correct zijn (juiste BIC chain) Fees kunnen per tussenbank verschillen Delay / cut-off times beïnvloeden settlement Fouten zitten vaak in: verkeerde correspondent ontbrekende/onjuiste routing info mismatch in nostro/vostro boeking Kern: Internationale betaling = keten van banken, niet 1-op-1 transactie. Les 11 — Cut-off times & value date (bank-specifieke logica) **begrepen ** Cut-off time Tijdslimiet per bank/valutasysteem Betaling vóór cut-off → zelfde dag verwerking Na cut-off → volgende werkdag Value date Datum waarop geld rente-technisch en juridisch beschikbaar is Kan afwijken van boekingsdatum Waarom dit belangrijk is voor testen Zelfde betaling → andere uitkomst afhankelijk van tijdstip Testcases moeten bevatten: vóór cut-off na cut-off weekend/feestdagen Valideren: juiste value date, juiste booking Kern: Tijd is een variabele in banking → beïnvloedt direct de uitkomst van transacties. Les 12 — Fees & charging (SHA / OUR / BEN) ** begrepen ** Drie charging types SHA (shared) → kosten gedeeld (meest gebruikt) OUR → verzender betaalt alle kosten BEN → ontvanger betaalt alle kosten Effect in de keten Correspondent banks kunnen kosten aftrekken Eindbedrag kan afwijken van initiële instructie Vooral bij internationale betalingen zichtbaar Waarom dit belangrijk is voor testen Valideren: eindbedrag bij begunstigde klopt met charging type Controleren: fees correct toegepast per stap Edge cases: meerdere correspondents → cumulatieve fees Kern: Niet alleen “is bedrag verstuurd”, maar komt het juiste bedrag aan volgens afgesproken charging model.