Artikel

Trade Stores: een database-checklist voor banken

De kans is groot dat er banken onvoorbereid zijn op het moment dat reguleringen als MiFID II en Dodd-Frank in werking treden. Van toezichthouders moeten al hun transacties kunnen reconstrueren, maar zonder de juiste tools is dat vrijwel onmogelijk. Om aan die veeleisende en veranderende regelgeving te voldoen, moet de transactiedata van banken van hoge kwaliteit zijn, en bovendien toegankelijk en doorzoekbaar zijn. Dit is waar een Trade Store bij kan helpen.

Een Trade Store is een platform binnen de informatie-infrastructuur dat een geïntegreerde ‘gouden standaard’ van data levert, opgeslagen op één locatie, en een compleet overzicht biedt. Banken kunnen hiermee gemakkelijker voldoen aan zowel bestaande als toekomstige regelgeving. De essentie is dat grote hoeveelheden ongestructureerde en gestructureerde gegevens over transacties in een centrale repository bij elkaar gebracht worden. Dit levert een uniforme, consistente en transparante registratie van elke transactie op, waarmee auditors en toezichthouders verzekerd zijn van een volledige audit trail. De vraag is nu: welke zaken moeten er op de checklist komen voor een geschikte Trade Store?

1. SQL/NoSQL
SQL of NoSQL, dat is de vraag. Beide databases (en zeker niet alleen SQL) hebben een rol bij banken en financiële instellingen. Maar we leven tegenwoordig in een multi-format wereld met een veelvoud aan content, waarin bovendien 80 procent van de data ongestructureerd is. Het probleem is dat een SQL-database is ontworpen om met gestructureerde data te werken. De veranderende aard, verscheidenheid en complexiteit van transactiedata lenen zich helaas niet voor een rigide schema-gebaseerd relationeel model.
Elk transactiesysteem introduceert weer een nieuw schema, dat vervolgens weer complexe interfaces vereist om de verschillende velden met elkaar te verenigen. En bij elke verandering, wat natuurlijk voorkomt, moet alles eerst volledig worden getest, maar regelmatig zelfs opnieuw ontworpen worden.
Nog een beperking van relationele databases is dat je al tijdens de beslissingsfase moet weten welke queries je in de toekomst gaat draaien. Relationele databases zijn in die zin gewoon niet wendbaar genoeg zijn om bedrijfskritische data uit verschillende silo’s te integreren.
NoSQL past veel beter bij deze moderne eisen, maar hoe kies je de juiste database? Veel NoSQL-databases bieden wel de benodigde flexibiliteit, maar open source-varianten hebben bijvoorbeeld niet altijd de enterprise-functies die nodig zijn. Denk aan functies als overheidsniveau security, elasticiteit, hoge beschikbaarheid, disaster recovery met geavanceerde replicatie en – het volgende item op de checklist – ACID-compliance.

2: ACID
ACID (Atomicity, Consistency, Isolation, Durability) staat voor een reeks eigenschappen die garandeert dat databasetransacties betrouwbaar worden verwerkt. Voor bedrijfskritische applicaties, bijvoorbeeld als er met financiële of gevoelige gegevens wordt gewerkt, is transactionele consistentie noodzakelijk. De bedrijfsrisico’s van niet-ACID systemen zijn groot, tenzij IT de complexe en arbeidsintensieve taak op zich neemt om ACID-compliance in al zijn applicaties te integreren.

Neem als voorbeeld een grote investeringsbank, die meer dan 100.000 complexe transacties per dag verwerkt. Die transacties resulteren in ongeveer 32 miljoen actieve deals in hun systeem op elk moment. Stel je voor welke chaos er zou ontstaan ​​als de gegevens van de bank niet 100 procent accuraat, consistent en up to date werden gehouden.

3: Schaalbaarheid
Met de Trade Store-aanpak kunnen banken niet alleen forse reguleringsboetes vermijden, ze kunnen ook hun kosten verlagen. Er is immers geen noodzaak meer om meerdere verschillende systemen te ontwikkelen en te onderhouden. In de nieuwe Enterprise NoSQL-wereld worden systemen gebouwd op een commodity scale-out architectuur. Het resultaat is een lagere kostprijs per transactie. Een bijkomend voordeel van de betere risicobeheersing die een Trade Store biedt, is dat banken normaliter minder kapitaal hoeven aan te houden van de regelgevers.
Belangrijk is verder dat het systeem ook snel aangepast, uitgebreid en verbeterd kan worden. Dit is noodzakelijk om aan veranderende zakelijke en wettelijke vereisten te voldoen zonder schema’s opnieuw te hoeven inrichten, of ETL (Extract, Transform en Load) toe te passen.

4: Semantiek
Een essentieel onderdeel van de nieuwe bancaire regelgeving is het kunnen aggregeren van risico- en financiële data van hoge kwaliteit. Semantiek maakt het makkelijker om allerlei afgeleide feiten en relaties te ontdekken, om vervolgens concepten en categorieën te creëren en meer context te verschaffen.
Door documenten, data en gekoppelde gegevens te combineren in één enkele architectuur, is het mogelijk om beter geïnformeerde beslissingen te nemen, risico's te verminderen, en meer accurate informatie voor het voetlicht te brengen.

5: Search
Search is net als een data-query een essentieel element van databasesoftware. Je kunt alle data verzamelen die je hebt, maar ze zijn praktisch onbruikbaar als het niet mogelijk is om ze te doorzoeken.
Het voordeel van een database met een ingebouwde zoekmachine is dat banken en financiële instellingen hiermee petabytes aan gegevens, opgeslagen in meerdere systemen, kunnen veranderen in bruikbare informatie. Een bijgebouwde search-oplossing zorgt ter vergelijking vaak voor tragere resultaten, lagere prestaties en minder nauwkeurigheid. Ook verlies je vaak de mogelijkheid om de nuances van de details te zien in de data, omdat de gegevens versnipperd (schredded) moeten worden. Hetzelfde probleem geldt ook voor third-party zoekmogelijkheden.

Een andere internationale bank die een Trade Store gebruikt, haalt nieuwe business intelligence voordelen uit de mogelijkheid om op nieuwe manieren transactiedata en KPI’s te kunnen doorzoeken en analyseren. Denk aan het ontdekken van nieuwe trends in hoe transacties plaatsvinden.  

6: Bitemporaal
Er zijn nu al meerdere toonaangevende banken bezig om een Trade Store te implementeren. De reden is dat zij het toekomstige belang zien van het kunnen bepalen wat er bekend was op een bepaald punt in de tijd. Als gevolg van deze trend, is een nieuwe functie ontwikkeld, genaamd bitemporaal datamanagement. Hiermee kunnen banken hun risico’s verlagen door middel van een soort technologisch tijdreizen. Dit werkt door middel van time stamping en het terugspoelen van documenten. Zo kunnen veranderingen geïdentificeerd worden  door te kijken naar de data zoals die waren in de loop der tijd, zonder data back-ups te hoeven herladen. Dit is kritisch voor het behouden en aantonen van compliance met bijvoorbeeld Dodd-Frank data-analyseprocessen.

Voor banken en financiële instellingen helpen deze bitemporale mogelijkheden om aan regelgeving te voldoen, audits te doorstaan, en risicomanagement en business analytics te verbeteren.

Bewezen aanpak
Banken moeten nu handelen om hun digitale archivering op orde te krijgen en te voorkomen dat ze massaal het slachtoffer worden van regulaire boetes, die in principe te vermijden zijn.
Met behulp van een enterprise NoSQL-database zijn een aantal van ‘s werelds grootste banken er al met succes in geslaagd om een Trade Store te implementeren. Daarmee kunnen zij rapportage voor regelgeving stroomlijnen, nieuwe diensten mogelijk maken die inkomsten genereren, de risico’s verminderen en de bedrijfsprocessen verbeteren.
Voor de regelgevers maakt het niet zoveel uit welke processen er precies worden gebruikt. Ze willen vooral in staat zijn om elk stukje data te controleren (van IM-logs tot individuele transacties), wanneer ze dat willen. Een Enterprise NoSQL-gebaseerde Trade Store biedt daarvoor een bewezen aanpak met een snelle ontwikkeling en implementatie.
Kortom: zorg ervoor dat je ACID, bitemporaal, NoSQL, Search, semantiek en schaalbaarheid van je database-checklist afvinkt. Dat is de beste manier om risico’s te minimaliseren en aan regulaire eisen te blijven voldoen. 

Categorie:   
Auteur(s)
afbeelding van jkrielaart
Jurriaan Krielaart
MarkLogic - Territory Director Northern Europe

Jurriaan Krielaart is een ervaren professional in de softwaremarkt met uitvoerige hands-on kennis van marketing, sales en partnerships. Hij is als Territory Director Northern Europe verantwoordelijk de groei van het ecosysteem van klanten, ontwikkelaars en de community van MarkLogic, een populaire enterprise noSQL database voor het integreren van datasilo's.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.