Interne transactieverwerking

Hoofdstuk 7

Interne transactieverwerking

Inleiding Het afsluiten en verwerken van een transactie in een financieel instrument verloopt volgens een vastgestelde procedure. In deze procedure worden achtereenvolgens de volgende activiteiten uitgevoerd: afsluiten van de transactie, invoeren van de transactiegegevens, autoriseren; verificatie; confirmeren en het geven van settlementinstructies. De afdelingen die deze operationstaken uitvoeren heten soms Operations of Service Centers. In dit boek wordt de universele naam back-office gebruikt. De verwerking van transacties vindt vaak plaats in verschillende computersystemen zoals een dealingsysteem, een front-office systeem, een back-office systeem en een confirmatiematchingsysteem. Financiële ondernemingen streven ernaar om de informatie-uitwisseling tussen deze systemen zoveel mogelijk automatisch te laten verlopen. Dit wordt stp of straight through processing genoemd. Tijdens verschillende fases in het verwerkingsproces sturen financiële ondernemingen informatie naar andere partijen. Hiervoor maken zij onder andere gebruik van swiftNet, een computernetwerk dat uitsluitend gebruikt wordt voor het versturen van financiële berichten.

126

Afwikkeling

7.1 Afsluiten van transacties en vastleggen van transactiegegevens Transacties in financiële instrumenten worden via de telefoon, via dealingsystemen of (electronic) brokers afgesloten. Handelaren mogen uitsluitend transacties afsluiten als zij daarvoor geautoriseerd zijn. Autorisatie betekent controle op de rechtmatigheid van een transactie. Een transactie is rechtmatig als de front-officemedewerker binnen zijn bevoegdheden blijft. Dat wil zeggen dat: – de front-officemedewerker in het afgesloten instrument mag handelen; – hij binnen zijn handelslimieten blijft; – hij door de transactie de tegenpartijlimiet niet overschrijdt. Vaak voert een front-officemedewerker voor het afsluiten van een transactie de transactiegegevens in zijn front-officesysteem om vooraf te controleren of de transactie geautoriseerd wordt. De controle op de handelslimiet vindt plaats in het front-officesysteem. De controle op de tegenpartijlimiet vindt plaats in een apart tegenpartijlimietensysteem dat gekoppeld is aan het front-officesysteem. Deze controle wordt pre-trade compliance genoemd. Het is ook belangrijk dat de front-officemedewerker de autorisatie van zijn tegenpartij controleert. Wanneer hij zijn reguliere contactpersoon aan de telefoon heeft, is er niets aan de hand. Maar wanneer deze persoon ziek is, of met vakantie moet de front-officemedewerker controleren of de tijdelijke contactpersoon bevoegd is om transacties af te sluiten. Nadat een transactie is afgesloten, worden de transactiegegevens in het front-officesysteem ingevoerd. Als de transactie telefonisch is afgesloten, gebeurt dit handmatig. Als de transactie via een dealingsysteem is afgesloten, wordt de transactie-informatie via een interface in het front-officesysteem ingelezen. In het front-officesysteem kan een handelaar daarna de marktwaarde en het risico van zijn positie bijhouden.


127

Als geen pre-trade compliance heeft plaatsgevonden en bij autorisatie achteraf blijkt dat de front-officemedewerker zijn handelslimiet heeft overschreden, moet hij de transactie in principe tegensluiten, tenzij de lijnmanager alsnog toestemming verleent. Als zou blijken dat de tegenpartijlimiet is overschreden, hangt het van de tegenpartij af wat er moet gebeuren. Als de tegenpartij bijvoorbeeld een vermogensbeheerder of een onderneming is, moet de cliëntadviseur achteraf aan de accountmanager toestemming vragen voor deze transactie. Meestal geeft de accoungmanager gehoor aan dit verzoek en hoeft de transactie niet te worden tegengesloten. Van elke transactie moeten de volgende gegevens in het frontofficesysteem worden ingevoerd: – de naam van de tegenpartij (counterparty); – de soortnaam van het financiële instrument, bij een effect ook de isin code (international securities identification number); – of het om een koop of om een verkoop gaat (buy/sale); – de valutasoort (currency), vaak door middel van een drieletterige iso-code bijvoorbeeld eur of usd; – het bedrag (notional amount, notional) of bedragen (bij fx transacties); – de looptijd van het contract (duration); – de koers (price of fx rate), de hoogte van de rente (interest rate); – bij een rente-instrument: de daycount convention; – bij een instrument met een variabele rente: de referentie van variabele rente (bijvoorbeeld euribor); – de afsluitdatum (trade date) en de tijd; – de naam van de handelaar (trader); – de settlementdatum; – de settlementinstructies. Financiële ondernemingen leggen in hun systemen zoveel mogelijk gegevens eenmalig vast zodat deze bij elke transactie niet steeds opnieuw ingevoerd hoeven te worden. Deze vaste gegevens worden static data genoemd. Static data van cliënten zijn bijvoorbeeld naw-gegevens, rekeningnummers, standaard settlement instruc-

128

Afwikkeling

ties (ssi) en, bij vermogensbeheer, mandaatgegevens. Ook van elk nieuw financieel instrument worden static data ingevoerd, zoals bijvoorbeeld de renteberekeningswijze en de valutasoort. Door het gebruikmaken van static data wordt de kans op invoerfouten verkleind. Het invoeren van de static data gebeurt op een aparte unit binnen de back-officeafeling. Financiële ondernemingen maken daarnaast vaak gebruik van raamovereenkomsten. Dit zijn overeenkomsten waarin alle voorwaarden en afspraken staan die gelden voor alle transacties in een bepaald instrument die een financiële onderneming afsluit met een en dezelfde tegenpartij. Telkens wanneer de financiële onderneming een transactie doet met deze tegenpartij verwijst zij naar de raamovereenkomst en zet uitsluitend de specifieke gegevens van de transactie in een apart contract. Voorbeelden van raamovereenkomsten zijn – isda Agreement (International Swap Dealers Organisation Agreement): voor rentederivaten, kredietderivaten of equityderivaten; – gmsla Agreement (General Master Securities Lending Agreement): voor securities lending transacties; – gmra Agreement (General Master Repurchase Agreement): voor repurchase agreements (repo’s); – ifema (International Foreign Exchange Master Agreement): voor valutatransacties. In raamovereenkomsten worden voor alle contracten die onder de raamovereenkomst vallen onder andere de volgende algemene zaken geregeld: – definities met betrekking tot de instrumenten en de afwikkeling; – de wetgeving die van toepassing is; – in hoeverre bilaterale contracten kunnen worden overgedragen aan andere partijen; – wie bevoegd zijn tot het afsluiten van transacties;


129

– welke informatie de partijen aan elkaar moeten verstrekken en met welke frequentie dit moet gebeuren, bijvoorbeeld een lijst van autorisaties van medewerkers. – op welke manier transacties geconfirmeerd worden. Vaak wordt naast een raamovereenkomst een apart contract afgesloten waarin bepalingen worden opgenomen die betrekking hebben op het tegenpartijrisico dat beide partijen lopen bij het afsluiten van transacties onder de raamovereenkomst. Deze aparte overeenkomst wordt een credit support annex genoemd (csa). In een csa staan bijvoorbeeld bepalingen over wie verantwoordelijk is voor het vaststellen van de waarde van de wederzijdse vorderingen en verplichtingen (calculation agent), over het wegstrepen van vorderingen tegen verplichtingen (netting), over het verstrekken van onderpand (collateral) en over maatregelen die genomen worden als een van de partijen zijn verplichtingen niet nakomt.

7.2 Verificatie Nadat een deal geautoriseerd is, worden de gegevens van het front-officesysteem naar het back-officesysteem gestuurd. In het back-officesysteem wordt gecontroleerd of alle gegevens van een afgesloten transactie zijn ingevoerd. Dit heet verificatie. Frontofficemedewerkers zijn vaak uitsluitend bezig met het afsluiten van transacties en schenken vaak minder aandacht aan het invoeren van de transactiegegevens. Ook vinden zij het vaak vervelend om aan de tegenpartij informatie te vragen over de afwikkeling van een transactie. Daarom maken zij regelmatig fouten bij het invoeren van de transactiegegevens. Bij eenvoudige financiële instrumenten zoals deposito’s, effecten en valutatransacties vindt de verificatie tegenwoordig automatisch plaats in het back-office systeem (stp). Bij meer ingewikkelde instrumenten, zoals rentederivaten en speciale beleggingsproducten, wordt de verificatie vaak nog handmatig uitgevoerd door gespecialiseerde back-officemedewerkers. In dit laatste geval moet de back-office proberen om eventuele fouten te signaleren om de ver-

130

Afwikkeling

dere verwerking goed te laten verlopen. Daarbij kan een back-officemedewerker de volgende kritische vragen stellen: – Lijken de settlement instructies juist? – Is er een item niet ingevuld in het invoerscherm? – Lijkt er iets vreemds aan de hand met de transactie, bijvoorbeeld: – een cliënt sluit een ander instrument dan anders; – een cliënt koopt een bepaalde valuta terwijl hij die altijd verkoopt; – er wordt een andere broker gebruikt dan normaal gesproken. – Is het afgesproken tarief marktconform? De laatstgenoemde controle wordt een reasonability check genoemd. Als het tarief afwijkend lijkt, moet een back-officemedewerker naar de dealer gaan om te controleren of de prijs inderdaad juist is. Omdat steeds meer transacties stp worden verwerkt, is een reasonability check door de back-office niet altijd mogelijk. Bovendien vereist een reasonility check behoorlijke kennis van zaken. Daarom vindt iedere dag een controle op ‘off-market pricing’ plaats door gespecialiseerde afdelingen: de afdeling Product Control bij banken of Investment Control bij vermogensbeheerders en beheerders van beleggingsfondsen.

7.3 Confirmatie Confirmatie of bevestiging is het afstemmen van de contractgegevens van een transactie met de tegenpartij. De confirmatie moet snel gebeuren zodat eventuele fouten in een vroeg stadium hersteld kunnen worden. Welke procedure gevolgd wordt bij confirmatie is afhankelijk van de soort transactie. Hieronder staan enkele gebruikelijke manieren van confirmeren:


131

1. Bij beurstransacties tussen een member en de beurs wordt de transactie direct elektronisch geconfirmeerd via het handelssysteem; 2. Bij transactie tussen twee banken sturen beide elkaar een swift bericht. Deze swift-berichten worden automatisch aangemaakt door de back-officesystemen van de banken. Voorbeelden van swift-confirmatieberichten zijn mt 300 voor valutatransacties (figuur 7.1), mt 320 voor deposito’s en mt 340 voor fra’s. Als een transactie via een broker is afgesloten, stuurt de broker ter bevestiging een swift-bericht naar beide contractpartijen; 3. Bij een transactie tussen een bank en een cliënt (belegger, vermogensbeheerder, institutionele belegger, onderneming) stuurt de bank meestal een fax of een e-mail aan de cliënt. Deze faxen of e-mails worden gemaakt door aparte systemen die worden gevoed door de back-officesystemen; 4. Bij financiele instrumenten die via Markit wire (Swapswire) worden afgesloten, wordt de transactie direct elektronisch geconfirmeerd. Markit wire kan gebruikt worden voor aandelen, aandelenderivaten, kredietderivaten en rentederivaten. Banken zijn wettelijk verplicht om een confirmatie te sturen naar hun tegenpartij. Dat is bijvoorbeeld ook het geval wanneer een cliënt een transactie afsluit via een autodealingsysteem van de bank. Het bevestigingsbericht van dit systeem geldt dus niet als confirmatie.

132

Afwikkeling

Figuur 7.1 Confirmatie door ing van een fx forward met ubs door middel van een swift mt 300 bericht soort informatie

swift-format

betekenis van de informatie

Message header Referentiecode

wchz0a1234ingb2a

Met behulp van deze code kunnen de matchingsystemen de berichten koppelen

swift-code verzender

ingbnl2a

ing Bank stuurt de confirmatie

swift-code ontvanger

wchzh80a

ubs Zwitserland ontvangt de confirmatie

Message text Trade date

20090522

Handelsdag 22 mei 2009

Value date

20090824

Settlementdatum 24

Exchange rate

1,3222

Currency, amount

usd 13.222.000

augustus 2009 Termijnkoers

bought Receiving agent

bofaus3n

ing wil de usd ontvangen op haar dollarrekening bij boa

Currency, amount sold

eur 10.000.000

Receiving agent

deutdeff

ubs wil de euro’s ontvangen op haar eurorekening bij Deutsche Bank

Dealing method

phon

De transactie is per telefoon gesloten


133

Matching van confirmaties Matchen van confirmaties is het controleren of de uitgestuurde confirmatie door de tegenpartij is geaccepteerd of dat de confirmatie die door een tegenpartij is verstuurd correct is. De manier waarop tegenpartijen op confirmaties moeten reageren is geregeld door middel van onderlinge afspraken. Bij transacties tussen een bank en een cliënt stuurt de bank een confirmatie waarop de cliënt moet reageren. Banken verlangen van hun cliënten vaak dat deze direct per e-mail of fax reageren op de door hun gestuurde confirmatie. Als een cliënt niet direct reageert, nemen banken bij fx- en Money Market transacties telefonisch contact op om de transactie te confirmeren. Soms geldt echter ook de afspraak dat als een cliënt aan het eind van de dag niet op een confirmatie heeft gereageerd deze als geaccepteerd wordt beschouwd. Bij transacties tussen twee banken is het gebruikelijk dat beide partijen elkaar een confirmatie sturen. Om deze confirmaties te matchen gebruiken banken aparte systemen. Sommige banken gebruiken een intern matchingsysteem. Andere banken maken gebruik van externe systemen zoals sna, dat wordt beheerd door swift. De matchingsystemen sturen elektronisch de status van de confirmaties naar het back-office systeem. Als de confirmaties overeenkomen, geven matchingsystemen een deal de status matched. Als een confirmatie ontbreekt of niet correspondeert, krijgt deze de status unmatched en komt deze in een queue te staan in het backofficesysteem. Verschillen in confirmaties kunnen betrekking hebben op de settlementinstructies van de transactie of op de transactiegegevens zelf. Bij een verschil in de settlementinstructies moet de back-office contact opnemen met de back-office van de tegenpartij. Als na de controle van de settlementinstructies met de back-office van de tegenpartij blijkt dat er een fout is gemaakt, moet de back-office van de partij die de fout heeft gemaakt deze gegevens wijzigen in zijn back-officesysteem. Hij stuurt daarvan een bevestiging naar de tegenpartij, de transactie krijgt dan alsnog de status matched en kan verder verwerkt worden.

134

Afwikkeling

Bij een verschil in de transactiegegevens moeten de back-officemedewerkers van beide partijen zo snel mogelijk contact opnemen met hun front-office. Als na controle met de front-office blijkt dat de gegevens fout zijn ingevoerd, moet de front-office de oorspronkelijke transactie in het front-officesysteem cancellen. Hiervoor is toestemming nodig van de lijnmanager. Daarna moet de transactie alsnog correct worden ingevoerd. Vervolgens stuurt de back-office een nieuwe confirmatie naar de tegenpartij. De fout is dan administratief hersteld, maar kan behoorlijke kosten met zich brengen. Voorbeeld Een salesman sluit een transactie af met een corporate client. De salesman begrijpt van de klant dat deze 12,5 mln usd wil verkopen aan de bank. Van de spot dealer krijgt hij een koers van eur/usd 1,2500. De klant gaat akkoord en de salesmen geeft de transactie direct door aan de spot dealer die direct zijn positie sluit door usd 12,5 miljoen te verkopen tegen de marktkoers van eur/usd 1,2500. De salesmen voert de transactie in het front-officesysteem in als een aankoop van usd. Omdat deze informatie correspondeert met de mondelinge informatie die hij van de salesman heeft ontvangen, kan de spot dealer niet vermoeden dat er iets mis is. Nadat de klant de confirmatie heeft teruggestuurd blijkt dat deze geen usd wilde verkopen, maar in plaats daarvan wilde kopen. De dealgegevens in de confirmaties matchen dus niet. De back-officemedewerker gaat naar de salesman en deze komt tot de conclusie dat hij inderdaad de verkeerde deal heeft afgesloten. De salesman cancelt de oorspronkelijke transactie en moet nu alsnog de juiste transactie boeken tegen de oorspronkelijk koers: de bank verkoopt 12,5 mln usd tegen een koers van eur/usd 1,2500. In het positieoverzicht van de handelaar wordt de oorspronkelijk transactie ook gecanceld. Nadat de salesman de transactie opnieuw heeft ingevoerd, heeft de spot dealer een positie waarbij hij twee keer een bedrag van usd 12,5 miljoen heeft verkocht tegen een koers van 1,2500 zonder dat daar een aankoop tegenover staat. De spot dealer heeft dus een shortpositie in dollars met een omvang van


135

usd 25 mln. Hij heeft daarvoor een bedrag van eur 20 mln ontvangen. Om de shortpositie in te dekken, moet de spot dealer direct usd 25 mln kopen. Als de koers op dat moment eur/usd 1,2400 is, moet hij daarvoor een bedrag van 25 mln / 1,2400 = eur 20.161.290,32 betalen. Als gevolg van de fout van de salesman verliest de spot dealer dus een bedrag van eur 161.290,32. Dit bedrag verhaalt hij op de salesdesk.

In het bovenstaande voorbeeld had de salesman van de eigen bank een fout gemaakt. Als blijkt dat de eigen front-officemedewerker de transactiegegevens goed heeft ingevoerd speelt het bovenstaande zich bij de tegenpartij af. Het komt ook voor dat zowel de eigen front-office als die van de tegenpartij overtuigd zijn dat zij de deal goed hebben ingevoerd. In dat geval moeten zij opnieuw contact met elkaar opnemen om te bepalen wat er werkelijk is afgesproken. Als zij er gedurende dit contact niet uitkomen, moeten zij zo snel mogelijk gebruik maken van de tape die van het gesprek is gemaakt.

7.4 Settlementinstructies Settlement is de uiteindelijke bij- of afboeking van geld en/of effecten uit hoofde van transacties in financiële instrumenten. Settlement vindt plaats bij banken, centrale banken, custodians en central securities depositories of bij een gespecialiseerde settlementinstelling zoals de cls-bank. De datum waarop de settlement plaatsvindt wordt settlementdatum of valutadatum (value date) genoemd. Om een afboekingen te laten plaatsvinden ten laste van de eigen rekening en ten gunste van een andere rekening moet een partij

136

Afwikkeling

een opdracht geven aan de instelling waar de nostrorekening loopt. Deze opdracht heet een overboekingopdracht of settlementinstructie. Banken sturen overboekingopdrachten via swiftNet. Vermogensbeheerders en beheerders van beleggingsfondsen voeren overboekingopdrachten rechtstreeks in het betaalsystemen van een bank in of van in het systeem van de custodians waar hun rekeningen lopen. Het opstellen van settlementinstructies vindt meestal automatisch plaats in een back-officesysteem. Het versturen van de overboekingopdrachten gebeurt door een aparte betaalafdeling of door een gespecialiseerde groep binnen de back-office. Dit gebeurt pas nadat een transactie door beide partijen is geconfirmeerd en het matchingsysteem de status matched aan deze transactie heeft gegeven. In jargon: nadat deze is vrijgegeven. Omdat banken zelf instellingen zijn waar rekeningen lopen, kan het voorkomen dat een bank uitsluitend een interne overboekingopdracht hoeft te sturen om een transactie te laten settelen. Als een salesmen van een bank bijvoorbeeld een kasgeldlening verstrekt aan een onderneming die een rekening aanhoudt bij diezelfde bank, hoeft de back-office uitsluitend een interne overboekingopdracht te sturen naar de afdeling die de rekeningen van de bank beheert. Deze opdracht luidt dan om de rekening van de onderneming te crediteren en een interne rekening op naam van Financial Markets/ Money Market te debiteren. Settlementinstructies moeten altijd voor een bepaald tijdstip worden verstuurd naar de settlementinstelling. De settlementinstelling moet namelijk nog tijd hebben om de overboekingen uit te voeren zodat het bedrag op de op de juiste valutadatum op de rekening van de begunstigde staat en daarnaast in staat zijn om het bedrag zelf rentedragend uit te zetten. Als dit het geval is, wordt in jargon gesproken van ‘good settlement value’. Het uiterste tijdstip waarop settlementinstructies kunnen worden verstuurd om sprake te laten zijn van good settlement value wordt cut-off tijd genoemd. De cutoff tijd voor overboekingen in euro’s die via target moeten worden afgewikkeld is bijvoorbeeld 17.30 uur en voor overboekingen die via Euro1 worden afgewikkeld 16.00 uur.


7.4.1

137

Schaduwoverboekingen en reconciliatie

Financiële instellingen houden van elke nostrorekening een interne schaduwrekening bij. Op deze schaduwrekeningen verwerken zij alle overboekingen die op de externe rekening plaats moeten vinden. Het back-officesysteem stuurt daarvoor een interne overboekingopdracht naar het systeem waarin de schaduwadministratie wordt bijgehouden. Als een bank bijvoorbeeld een overboeking in usd moet doen, stuurt zij een externe overboekingopdracht naar de dollarcorrespondentbank om de usd-nostrorekening te debiteren en een interne overboekingopdracht naar het eigen rekeningsysteem om de schaduwrekening van deze usd-nostrorekening te debiteren. Als de bank vervolgens een transfer statement ontvangt van de correpondentbank (mt910), kan zij deze vergelijken met de mutatie in de schaduwadministratie. Deze controle wordt reconciliatie genoemd en wordt meestal uitgevoerd door een aparte unit binnen de back-office: operations control.

7.4.2

Standaard settlementinstructies (ssi)

Als een frontoffice medewerker veel transacties afsluit met een bepaalde klant, is het onhandig om bij elke afzonderlijke transactie alle gegevens steeds opnieuw in te voeren. Daarom is het gebruikelijk dat hij met zijn klant afspreekt welke rekeningen gewoonlijk gebruikt moeten worden bij de afwikkeling. Deze instructies worden standaard settlement instructies genoemd, of ssi. ssi behoren tot de static data van een cliënt. Als een front-officemedewerker een transactie afsluit met een cliënt mag hij ervan uitgaan dat deze volgens de ssi afgewikkeld moet worden. Als de cliënt wil dat de overboeking naar een andere rekening plaatsvindt, moet hij dat duidelijk aangeven. Back-office medewerkers moeten alert zijn als sprake is van afwijkende settlementinstructies. Zij moeten dan bij de front-office controleren of de settlementinstructies juist zijn. Als de begunstigde een derde partij is, moeten zij helemaal opletten. In dit geval kan zelfs sprake zijn van fraude.

138

7.4.3

Afwikkeling

Risico’s van settlement

Het risico dat een binnenkomende overboeking niet of te laat plaatsvindt heet settlementrisico. Het risico dat een uitgaande overboeking niet of te laat plaatsvindt, heet operationeel risico. Bij effectentransacties en valutatransacties kan settlementrisico vermeden worden door de overboekingen afhankelijk van elkaar te maken. Dat is het geval wanneer een valutatransactie via de cls bank wordt gesetteld (payment versus payment) en wanneer een effectentransactie volgens de dvp conditie (delivery versus payment) wordt afgewikkeld. Een andere manier om het settlementrisico te verminderen is gebruikmaken van payment netting. Dit houdt in dat tegengestelde betalingen die op eenzelfde valutadatum met een en dezelfde partij plaatsvinden uit hoofde van een of meer transacties met elkaar worden gecompenseerd en dat alleen het gesaldeerde bedrag wordt overgeboekt. Voorbeeld Een bank heeft op 13/7/2009 een receiver’s renteswap afgesloten met hoofdsom van eur 10.000.00,-. De vaste rente is vastgesteld op 3% (30/360). De variabele rentecoupon is op basis van 6-maands euribor. In de isda Agreement zijn de partijen overeengekomen dat de vaste couponbetaling genet wordt met een variabele couponbetaling als deze op dezelfde valutadatum vallen. Op 13/1/2010 is het 6-maands euribor voor de couponperiode 15/1/2010 – 15/7/2010 gefixeerd op 2% (actual/ 360, 181 dagen). De hoogte van de couponbetalingen per 15/7/2010 bedraagt: Vaste rentecoupon 1e jaar: eur 100 mln x 3% x 360/360 = eur 3.000.000,Variabele rentecoupon 15/1/2010 – 15/7/2010: eur 100 mln x 2% x 181/360 = eur 1.005.555,55


139

De bank ontvangt op 15/7/2010 het nettobedrag van eur 1.994.444,45 van de tegenpartij.

7.5 Event calendar Bij een aantal financiële instrumenten vindt niet uitsluitend een overboeking plaats bij of direct na het afsluiten van een transactie, maar vinden ook overboekingen plaats gedurende de looptijd van het contract. Deze overboekingen worden geagendeerd in een event calendar. Dit is een lijst met gebeurtenissen tijdens de looptijd van een contract die om actie van de back-office vragen. Deze lijst wordt vastgelegd in een apart computersysteem. De acties in een event calendar kunnen ook betrekking hebben op refixing van couponrente, periodiek vaststellen of de omvang van onderpand moet worden gewijzigd, uitvoeren of innen van dividendbetalingen of uitvoeren van een vervroegde aflossing. In figuur 7.3 staat een voorbeeld van een event calendar van een interest rate swap. Figuur 7.3 Event calendar van een 3-jaars receiver’s interest rate swap die op 13/7/2009 is afgesloten datum

event

13/1/2010

Fixeren 6 maands euribor Couponperiode 15/1/2010 – 15/7/2010

15/1/2010

Betalen variabele coupon Couponperiode 15/7/2010 – 15/1/2011

13/7/2010


15/7/2010

Ontvangen saldo vaste coupon 1e jaar en variabele coupon periode 15/1/2010 – 15/7-2010

13/1/2011

Fixeren 6 maands euribor

17/1/2011

Betalen variabele coupon

Couponperiode 17/1/2011– 15/7/2011 Couponperiode 15/7/2010 – 17/1/2011

140

Afwikkeling

13/7/2011


15/7/2011

Ontvangen saldo vaste coupon 2e jaar en variabele coupon periode 17/1/2011 – 15/7-2011

13/1/2012


17/1/2012

Betalen variabele coupon Couponperiode 15/7/2011 – 17/1/2012

17/7/2012

Ontvangen saldo vaste coupon 3e jaar en betalen variabele coupon periode 17/1/2012 – 17/7-2012

7.6 Schematische voorstellingen verwerkingsprocessen In deze paragraaf worden een aantal werkprocessen bij de backoffice beschreven. Eerst worden de verschillende stadia van de verwerking van een fx transactie en van een otc-effectentransactie bij een bank beschreven. Daarna wordt aangegeven hoe de verwerking van een structured product verloopt.

Interne transactieverwerking

Recommend Documents