Topicus FORCE Framework Whitepaper
Inhoudsopgave 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. 1.7. 2.1.
Zoveel mogelijk geautomatiseerde afhandeling van processen (STP) ..................... 4 Korte time-to-market voor de introductie van nieuwe producten en processen .... 5 Distributie naar ketenpartners via het “common workspace” concept .................. 5 Herbruikbaarheid van componenten, ongeacht het bedrijfsproces ........................ 6 Directe link met de eindconsument ......................................................................... 7 De executie van campagnes is onderdeel van de front- en midoffice ..................... 8 Mid- en backoffice als één applicatie ....................................................................... 8 Distributie ............................................................................................................... 11
2.1.1. Flexibele webforms ....................................................................................................... 11 2.1.2. HDN in- en export ......................................................................................................... 12 2.1.3. Common workspace ..................................................................................................... 13
2.2. User Interaction ...................................................................................................... 14 2.2.1. Applicatieschermen ...................................................................................................... 14 2.2.2. Styling............................................................................................................................ 14 2.2.3. User controls ................................................................................................................. 15
2.3. Toetsing................................................................................................................... 15 2.3.1. Business Rule Engine..................................................................................................... 15 2.3.2. Acceptatiekaders .......................................................................................................... 16 2.3.3. Genereren stukkenlijst .................................................................................................. 17 2.3.4. Genereren bijzondere bepalingen ................................................................................ 17 2.3.5. Externe toetsingen ........................................................................................................ 17
2.4. Procesbesturing ...................................................................................................... 18 2.4.1. Workflow Manager ....................................................................................................... 18 2.4.2. Taken............................................................................................................................. 19 2.4.3. Events............................................................................................................................ 20 2.4.4. Triggers ......................................................................................................................... 20 2.4.5. Operationele rapportages ............................................................................................ 20
2.5. Rekenmodules ........................................................................................................ 22 2.6. Authenticatie & autorisatie .................................................................................... 23 2.6.1. Authenticatie ................................................................................................................ 23 2.6.2. Rollen- & rechtenbeheer .............................................................................................. 24
2.7. Product & pricing .................................................................................................... 24 2.7.1. Productmodel ............................................................................................................... 25 2.7.2. Provisiemodel ............................................................................................................... 25 2.7.3. Rentemodel................................................................................................................... 25 2.7.4. Risicomodel ................................................................................................................... 26 2.7.5. Kenmerken .................................................................................................................... 26 2.7.6. Afspraken en modules .................................................................................................. 27
2.8. Gegevensintegriteit ................................................................................................ 27 2.8.1. Correctheid & compleetheid ........................................................................................ 28 2.8.2. Audittrail ....................................................................................................................... 28
2 van 38
2.9. Dossiermanagement ............................................................................................... 29 2.9.1. Output management .................................................................................................... 29 2.9.2. Archiefbeheer ............................................................................................................... 29
2.10. Financiële afhandeling .......................................................................................... 30 2.10.1. Boekingen ................................................................................................................... 30 2.10.2. Betalingscondities ....................................................................................................... 30 2.10.3. Betalingsstekkers ........................................................................................................ 31 2.10.4. Vervalkalender ............................................................................................................ 31
2.11. Contractbeheer ..................................................................................................... 31 2.11.1. Overeenkomstenbeheer ............................................................................................. 32 2.11.2. Versiebeheer ............................................................................................................... 32 2.11.3. Zekerheden administratie........................................................................................... 33 2.11.4. Bijzonder beheer......................................................................................................... 33 2.11.5. Securitisatie ................................................................................................................ 34
3.1. Koppelingen met externe systemen ....................................................................... 35 3.2. Koppelingen met interne systemen........................................................................ 37
3 van 38
1. Topicus FORCE: full-finance ondersteuning in front-, mid- en backoffice Topicus Finance richt zich op de ICT-matige ondersteuning van bedrijfsprocessen in de financiële sector. Dit doet Topicus met behulp van het FORCE framework, een componentgebaseerd raamwerk dat in staat is om praktisch elk financiëel proces verregaand geautomatiseerd te ondersteunen. De visie van Topicus op ondersteuning van bedrijfsprocessen in de financiële sector is gebaseerd op de volgende kerngedachten: 1. 2. 3. 4. 5. 6.
1
zoveel mogelijk geautomatiseerde afhandeling van processen (STP) korte time-to-market voor de introductie van nieuwe producten en processen distributie naar andere partijen is mogelijk via het “common workspace” concept componenten zijn herbruikbaar, ongeacht het te ondersteunen bedrijfsproces directe link met de eindconsument (customer self service) de executie van campagnes is onderdeel van de front- en midoffice 7. mid- en backoffice zijn te ondersteunen middels één applicatie
1.1. Zoveel mogelijk geautomatiseerde afhandeling van processen (STP) In de visie van Topicus is er een duidelijke onderverdeling aan te brengen in de onderdelen van een bedrijfsproces: enerzijds zijn er processtappen en handelingen die eenduidig in deterministische modellen, regels en logica te modelleren zijn (bijvoorbeeld de toetsing van een standaard hypotheekaanvraag tegen het acceptatiekader), anderzijds zijn er processtappen die juist aan de specialistische kennis en de deskundige beoordeling van een medewerker moeten worden overgelaten (bijvoorbeeld de afweging om bij een niet-standaard aanvraag die niet binnen het acceptatiekader past toch tot hypotheekverstrekking over te gaan).
Alle onderdelen van een proces die eenduidig en consequent op dezelfde wijze worden afgehandeld zijn uitermate geschikt voor volledig geautomatiseerde afhandeling (StraightThrough Processing zonder tussenkomst van een medewerker). Voor alle onderdelen van het proces waarvoor dit niet of slechts in mindere mate geldt, is het juist zaak om dit niet volledig geautomatiseerd af te handelen. Er is sprake van een continue trade-off tussen enerzijds efficiency en anderzijds risico.
De kunst zit erin om hier de balans in te vinden en om deze balans ook te houden. Of de nadruk nu ligt op efficiency of juist op risico is namelijk zeer dynamisch en sterk conjunctuurgevoelig. Dit vraagt een hoge mate van flexibiliteit van een platform dat dergelijke bedrijfsprocessen ondersteunt, zodat op het moment dat er een verschuiving in de balans plaatsvindt, dit met een zo kort mogelijke time-to-market in alle bedrijfsprocessen die het platform ondersteunt kan worden doorgevoerd. Met het FORCE framework behoort dit in de visie van Topicus absoluut tot de mogelijkheden.
4 van 38
2 1.2. Korte time-to-market voor de introductie van nieuwe producten en processen Financiële dienstverleners willen snel in kunnen springen op veranderende marktomstandigheden, door bijvoorbeeld nieuwe producten te lanceren, bestaande producten aan te passen en processen anders te laten verlopen. De FORCE componenten zijn zo opgezet, dat de dienstverlener deze acties zo veel mogelijk zonder tussenkomst van ICT kan uitvoeren: functioneel beheerders kunnen zelf producten en processen toevoegen of wijzigen. Ditzelfde geldt andere voor autorisatie, rente, acceptatieregels en op te vragen dossierstukken.
3
1.3. Distributie naar ketenpartners via het “common workspace” concept Bij financiële product- en dienstverlening zijn doorgaans diverse partijen betrokken. Uiteraard zijn dit de eindconsument en de product- of dienstverlener (banken, geldverstrekkers, verzekeraars), maar vaak zijn er ook diverse andere partijen bij betrokken, zoals werkgevers, tussenpersonen, packagers, servicers makelaars, taxateurs en notarissen. In de visie van Topicus is het mogelijk om al deze partijen te ondersteunen via één platform, dat via een “common workspace” concept delen functionaliteit uitserveert naar alle betrokken partijen. Alleen die functionaliteit die een partij nodig heeft om zijn taken binnen het totale proces uit te voeren wordt beschikbaar gesteld. FORCE ondersteunt dit door webapplicaties volgens het SaaS (Software As A Service) concept te implementeren.
Figuur 1 - Aansluiting van verschillende ketenpartners op de common workspace
5 van 38
Op deze wijze is er sprake van één platform waar alle partijen op aanhaken. Hiermee is een enorme efficiency-slag te behalen; daar waar in het verleden de overdracht van een dossier (bijvoorbeeld een aanvraag) veel tijd in beslag nam omdat dit nog via de post ging of omdat gekoppelde systemen slecht op elkaar aansloten is er nu sprake van één platform met één onderliggend gegevensmodel, waardoor overdracht niet alleen binnen een oogwenk plaatsvindt, maar tevens uniformiteit in gegevens is gewaarborgd.
4
1.4. Herbruikbaarheid van componenten, ongeacht het bedrijfsproces In de filosofie van Topicus is het in beginsel mogelijk om alle bedrijfsprocessen te ondersteunen met behulp van de FORCE componenten. Ongeacht of het nu gaat om een front-, mid- of backoffice proces, er is altijd één grote gemene deler van functionaliteit te onderkennen die in vrijwel elk bedrijfsproces weer terugkomt. Of het nu bijvoorbeeld gaat om een adviestraject, de afhandeling van een hypotheekaanvraag, het afsluiten van een verzekering of het aflossen van een krediet, bij de geautomatiseerde ondersteuning van deze bedrijfsprocessen is (vrijwel) altijd sprake van: • • • • • • • • •
gegevensadministratie gegevensdistributie procesbesturing toetsing en beoordeling product & pricing output management document management financiële verwerking authenticatie en autorisatie
Binnen deze “themagebieden” heeft Topicus een gereedschapskist aan componenten en koppelingen gerealiseerd die samen het FORCE framework vormen. De componenten zijn bij diverse partijen succesvol ingezet waarbij binnen afzienbare tijd hoogwaardige financiële applicaties zijn gerealiseerd. Daarbij vindt continue doorontwikkeling van het framework plaats, zodat de componenten in staat zijn om zeer complexe klantwensen en –eisen te ondersteunen.
6 van 38
Figuur 2 - Hergebruik van componenten bij verschillende bedrijfsprocessen
Door het feit dat vrijwel elk bedrijfsproces altijd dezelfde themagebieden “raakt” te combineren met een gereedschapskist met losse, discrete componenten is in hoge mate hergebruik van de componenten mogelijk. Nadat in een implementatietraject eenmaal de basis componentenarchitectuur is gerealiseerd, is het daarna veelal een kwestie van uitbouwen (naast generieke functionaliteit is er onherroepelijk ook altijd bedrijfsprocesspecifieke functionaliteit nodig) en meer en meer bedrijfsprocessen met deze set van componenten te gaan ondersteunen.
5
1.5. Directe link met de eindconsument Door het Internet heeft customer self servicing een enorme vlucht genomen. Financiële instanties bieden steeds vaker online diensten aan de eindconsument, tegelijkertijd verwacht de consument deze diensten. De website van de financiële instelling biedt de consument een direct kanaal voor onder andere het: • • • •
aanvragen van producten; doorgeven van wijzigingen; verkrijgen van advies; uitvoeren van berekeningen.
De consument neemt hierdoor (deels) het werk over dat traditioneel uitgevoerd werd door het kantorennet of de telefonische helpdesk. Door gedurende de verwerking de klant via Internet of email automatisch op de hoogte te houden van de voortgang wordt de telefonische helpdesk nog verder ontlast. Topicus vindt dat de corporate website van de financiele instelling naadloos moet aansluiten op de interne procesverwerking en biedt hier met het FORCE framework een oplossing voor. De formulieren op de site sturen de aanvraag- of mutatiegegevens naar FORCE, waar het proces voor het verwerken van de gegevens gestart wordt. Veelal zal dit een geautomatiseerd proces zijn, bijvoorbeeld bij het aanvragen van een spaarrekening verzorgt FORCE het versturen van contracten en stuurt FORCE het afgeleide identificatie proces aan. Alleen in bijzondere situaties legt FORCE de aanvraag voor aan een gebruiker (bijvoorbeeld als de tenaamstelling van de 1 cent boeking voor afgeleide identificatie niet juist is). 7 van 38
6
1.6. De executie van campagnes is onderdeel van de front- en midoffice Ten aanzien van campagnes maakt Topicus onderscheid tussen projectmarketing en procesmarketing. Projectmarketing is het traditionele campagneproject met een begin- en einddatum en met binnen het project vaste opvolgende fasen. Onder procesmarketing verstaat Topicus het acteren op klantgebeurtenissen op basis van het profiel van de klant. De klantprofielen kunnen steeds fijnmaziger gemaakt worden zodat 1-op-1 marketing steeds dichterbij komt (de klant wordt benaderd op relevante momenten met voor de klant relevante informatie).
FORCE biedt voor zowel de uitvoering van projectmarketing als voor procesmarketing een campagne management oplossing die direct van alle kanalen gebruik kan maken (Internet, kantoren, service center, post, email, outbound calling). Het inzetten van FORCE voor projecten procesmarketing zet een hefboom op de bestaande infrastructuur van systemen, medewerkers, processen en organisatie. Door bijvoorbeeld de idle-time op de kantoren en het service center in te zetten voor campagnes wordt het aantal medewerkers dat in potentie een bijdrage kan leveren aan de uitvoering van een campagne met een zeer significante factor vergroot.
7
1.7. Mid- en backoffice als één applicatie Vanuit de klassieke invalshoek op financiële producten is meestal een knip geplaatst tussen midoffice en backoffice, oftewel tussen het commerciële proces en het administratieve proces. In de visie van Topicus zijn de daarbij betrokken partijen, processen, gegevens en dataentiteiten echter dermate sterk met elkaar verweven dat de ondersteuning van mid- en backoffice pas optimaal is als dit gebeurt vanuit één overkoepelend platform. Voor het hypotheekproces is dit weergegeven in onderstaande figuur.
Figuur 3 – Benodigdheden voor ondersteuning Mid- en Back Office hypotheekprocessen
In de praktijk gaat het bij het omzetten van een aanvraag naar een overeenkomst voor een groot deel nog steeds om dezelfde contractanten, dezelfde inkomensgegevens, dezelfde zekerheden en dezelfde productsamenstelling. Het is dus niet meer dan logisch om ook één datamodel voor zowel mid- als backoffice te hanteren. Daarnaast geldt dat (zoals uit 8 van 38
bovenstaande figuur blijkt) de geautomatiseerde ondersteuning van mid- en backoffice processen voor het overgrote deel gebruik maakt van dezelfde functionaliteit en dezelfde functionele componenten, ongeacht het te ondersteunen bedrijfsproces. Het enige verschil zit in de inhoudelijke invulling van de componenten om een mid office danwel back office proces te kunnen ondersteunen; de achterliggende mechanismen en technieken zijn echter telkens hetzelfde. Ook dit pleit ervoor om mid- en backoffice te ondersteunen met één applicatie.
FORCE past multi-knip toe. Dat wil zeggen dat FORCE zowel de front-, mid- en backoffice functionaliteit aanbiedt en de verwerking desgewenst in een van deze ketenonderdelen in en uit kan stappen. FORCE kan dus op meerdere manieren ingezet worden, bijvoorbeeld als totaaloplossing of alleen als front-, en midoffice waarbij een third party backoffice gebruikt wordt. FORCE biedt verschillende interfaces om te koppelen met third party systemen, zo kan het productmodel ontsloten worden (inclusief tarifering en productkenmerken) en kan FORCE aanvraag- en mutatiegegevens importeren en exporteren.
9 van 38
2.
De componenten van het FORCE framework Het FORCE framework bevat diverse componenten die elk functionaliteit op een specifiek gebied leveren. Door de juiste componenten met elkaar te combineren is het FORCE framework in staat om verschillende financiële bedrijfsprocessen te ondersteunen. De FORCE componenten leggen de basis voor ieder mogelijk financieel proces. Met behulp van de componenten is het vervolgens mogelijk om een specifiek proces eenvoudig uit te werken in applicatielogica.
De componenten zijn toe te passen op bijvoorbeeld het hypotheekaanvraagproces, aanvragen en mutaties voor betaal-, spaar en verzekeringproducten. Voor hypotheken en kredienten zijn de FORCE componenten ook uitstekend in staat om bijvoorbeeld het passeerproces, het bouwdepotproces, wijziging bestaande hypohteek (WBH) processen en administratieve processen te ondersteunen.
Alle FORCE-componenten zijn ondergebracht in functionele categorieën. Zo zijn er bijvoorbeeld FORCE componenten op het gebied van procesbesturing, toetsing en product & pricing. Daarnaast bevat FORCE een veelvoud aan koppelingen met zowel externe systemen (denk daarbij aan BKR, NHG) en interne systemen (zoals een outputmanagement systeem of een documentmanagement systeem). De verschillende functionele categorieën zijn schematisch weergegeven in de volgende figuur:
Figuur 4 - De categorieën van het FORCE framework
Door het schema van figuur 1 verder in te vullen met de diverse FORCE componenten en koppelingen ontstaat het gedetailleerde componentenoverzicht (zie figuur 5). Daarbij maakt Topicus onderscheid tussen componenten die zorg dragen voor ontsluiting van de applicatie (oftewel de user interface en de distributie van gegevens en functionaliteit), componenten die bijdragen aan de inhoudelijke verwerking, componenten voor de aansturing van de verwerkingsprocessen en faciliterende componenten voor bijvoorbeeld de ondersteuning van WFT en SAS70.
10 van 38
Figuur 5 - Detailoverzicht FORCE componenten per categorie
8
2.1. Distributie De categorie “Distributie” bevat alle FORCE componenten die de eindconsument betrekken in het proces en die zorgen voor het ontsluiten van functionaliteit aan andere partijen (externe stakeholders) in de “value-chain” van het gehele hypotheekproces, zoals tussenpersonen, packagers, servicers en geldverstrekkers.
8.1
2.1.1. Flexibele webforms FORCE biedt webparts waarmee de financiële instelling zelf de webformulieren van de corporate website kan opbouwen en wijzigen. Hierdoor is de instelling volledig vrij in het inregelen van de processen van voor tot achteren. Daarnaast biedt FORCE meetinstrumenten waarmee het gebruik van de formulieren gemeten kan worden. Zo is bijvoorbeeld inzichtelijk bij welke stap in het proces een prospect afhaakt (tot op veldniveau). De financiële instelling kan op basis van dit inzicht zelf het proces bijsturen.
11 van 38
Corporate website formulier Label x Label y Label z
Webpart Webpart Webpart FORCE.Webparts
SOAP XML XML Gateway Intranet Xml asynchroon Productkenmerken
FORCE
Inlezen procesgegevens
Internet
FORCE biedt een interface voor de corporate website, zodat de website onder andere looptijden, tarieven en productkenmerken (bijvoorbeeld minimum inleg, maximale hoofdsom) kan ophalen. De webparts gebruiken deze gegevens voor informeren van de klant, uitvoeren van berekeningen (bijvoorbeeld “hoeveel kan ik lenen”) en validatie van aanvraaggegevens.
De website stuurt de aanvraag- of mutatiegegevens door naar FORCE, waar de verwerking van het STP proces start. FORCE verstuurt een bevestingsmail en gedurende het proces statusupdates per email. Zonodig kan een medewerker naar aanleiding van het proces vragen aan de klant sturen per email, antwoorden op deze vragen pakt FORCE weer op en koppelt deze aan het proces.
8.2
2.1.2. HDN in- en export Communicatie tussen verschillende partijen op het gebied van hypotheken gebeurt veel via het Hypotheken Data Netwerk (HDN). Communicatie vindt plaats op basis van diverse gestandaardiseerde HDN-berichten. De FORCE HDN in- en exporter is in staat om diverse typen HDN-berichten te importeren (waarbij de component HDN-berichten omzet naar de interne datastructuur) en te exporteren (waarbij de component op basis van de interne datastructuur een HDN-bericht genereert). Op dit moment ondersteunt de component de volgende HDNberichttypen: • • •
AX (aanvraagbericht) OX (offertebericht) SX (statusbericht)
Naast deze berichttypen werkt de HDN-organisatie aan nieuwe typen HDN-berichten, te weten: • • • •
BX (ter ondersteuning van communicatie over bankgaranties) DA/DX (ter ondersteuning van communicatie over aan te tonen stukken) PX (ter ondersteuning van communicatie over provisies) TX (ter ondersteuning van communicatie over taxaties)
12 van 38
Topicus volgt de HDN-standaard en op het moment dat deze nieuwe berichtstandaarden beschikbaar zijn en een klant deze wil gebruiken in haar proces, voegt Topicus deze toe aan de FORCE HDN-component. De integratie van een specfieke afhandeling van een HDN bericht in een bedrijfsproces verschilt veelal tussen organisaties en is doorgaans maatwerk.
8.3
2.1.3. Common workspace FORCE ondersteunt het “Common workspace” concept, beschreven in hoofdstuk 1, op twee manieren: 1. 2.
door ontsluiting van een met FORCE gerealiseerde applicatie aan diverse partijen door de ontsluiting van track & trace gegevens of deelfunctionaliteit via webservices
Bij het common workspace principe is de FORCE applicatie zodanig ingeregeld dat medewerkers van externe partijen toegang hebben tot het systeem. Op basis van autorisaties is ingeregeld tot welke onderdelen van de FORCE applicatie en gedurende welke stadia van het proces een medewerker van een externe partij toegang heeft. Op deze wijze is de medewerker van een externe partij in staat om in de FORCE applicatie zijn specifieke werkzaamheden uit te voeren alvorens de aanvraag weer over te dragen aan de medewerker van een andere partij. Op deze manier is een deel van het proces via de webapplicatie ontsloten naar een externe partij.
Figuur 6 – Werkvoorraad in de common workspace
In het tweede geval ontsluit FORCE met behulp van op SOAP en XML gebaseerde webservices gegevens richting een externe applicatie, zodat de externe applicatie een deel van het proces af kan handelen. Daar waar mogelijk maakt FORCE daarbij gebruik van bestaande standaarden en services, zoals bijvoorbeeld HDN. Daar waar de communicatie met andere partijen echter niet via HDN plaats kan vinden (bijvoorbeeld omdat een partij niet op HDN is aangesloten), is het
13 van 38
mogelijk om gegevens en functionaliteit via andere webservices te ontsluiten. Aangezien verschillende partijen veelal behoefte hebben aan verschillende gegevens en verschillende functionaliteit, betreft het hier meestal maatwerk services.
9
2.2. User Interaction De categorie “User Interaction” bevat alle FORCE componenten met behulp waarvan het mogelijk is om in korte tijd de benodigde applicatieschermen ter ondersteuning van een specifiek bedrijfsproces te realiseren.
9.1
2.2.1. Applicatieschermen Om een bedrijfsproces te kunnen ondersteunen zijn doorgaans applicatieschermen nodig waarmee de gebruiker gegevens kan opvoeren of wijzigen en de benodigde handelingen en acties uit kan voeren. Applicatieschermen vallen uiteen in: • •
beheerschermen (om functioneel applicatiebeheer uit te voeren) processchermen (om het daadwerkelijke bedrijfsproces uit te voeren)
Applicatieschermen zijn in meer of mindere mate herbruikbaar over verschillende processen. Bij zowel het aanvraagproces als diverse mutatie-processen zijn bijvoorbeeld schermen nodig voor het inzien en wijzigen van de gegevens van de contractant, het onderpand of de financiering / het product. Dergelijke applicatieschermen zijn dus goed herbruikbaar. Een scherm voor het afhandelen van renteafkoop daarentegen is zeer specifiek voor de afhandeling van vervolghypotheken en verhogingen en daardoor in mindere mate herbruikbaar. Het FORCE framework bevat basisschermen voor de ondersteuning van diverse bedrijfsprocessen, waaronder: • • • •
het aanvraagproces diverse wijzigingsprocessen (productmutaties en in het kader van WBH’s (wijzigen bestaande hypotheek)) het passeerproces het declaratieproces m.b.t. bouwdepots
De basis applicatieschermen zijn in beginsel direct inzetbaar, maar moeten vaak nog wel op maat worden gemaakt binnen een specifieke implementatie. De ene partij stelt immers andere eisen aan de applicatieschemen dan de andere (in termen van welke invoervelden er exact getoond moeten worden, hoe de velden heten, welke schermcontroles er uitgevoerd moeten worden, et cetera).
9.2
2.2.2. Styling De styling component bepaalt het volledige uiterlijk van een met FORCE componenten gerealiseerde webapplicatie. Vormgeving, layout, schermresolutie en kleurgebruik vallen onder de verantwoordelijkheid van dit component. De styling component bestaat doorgaans uit: • • •
Cascading Style Sheets (CSS) Grafische elementen (logo’s, iconen, afbeeldingen, et cetera) Pagina-templates
14 van 38
Nadat de styling component eenmaal is ingeregeld maken alle applicatieschermen gebruik van dit component, zodat één uniforme look-and-feel van de applicatie ontstaat, ook als in een later stadium nieuwe applicatieschermen ter ondersteuning van nieuwe bedrijfsprocessen worden toegevoegd.
9.3
2.2.3. User controls User controls zijn verzamelingen van schermelementen (zoals invoervelden, navigatie-menu’s) die op meerdere applicatieschermen nodig zijn. Zo bevat FORCE standaard user controls voor bijvoorbeeld een persoon (geslacht, titel, voorletters, tussenvoegsel, achternaam, familienaam) en een adres (straat, huisnummer, toevoeging, postcode, plaats). Bij het realiseren van een applicatiescherm is het hierdoor mogelijk om in één keer een user contol toe te voegen in plaats van alle “losse” invoervelden of schermelementen afzonderlijk. Bovendien is hiermee tevens de consistentie binnen de applicatie voor een deel gewaarborgd.
Figuur 7 - Gebruik van de tabbladen user control in een FORCE applicatie
In een aantal standaard user controls zijn tevens generieke validaties beschikbaar. Voor diverse gegevens geldt een standaard validatie en/of toegestane invoer. Zo dient een Nederlandse postcode altijd te bestaan uit vier cijfers en twee letters, een datum moet in het formaat “DDMM-JJJJ” zijn en moet een bankrekening voldoen aan de elf-proef. Dergelijke generieke validaties zijn vastgelegd in dit component, zodat hergebruik in verschillende applicatieschermen mogelijk is.
10
2.3. Toetsing Binnen de categorie toetsing vallen alle toetsingen ten behoeve van klanten en derde partijen die nodig zijn voor bijvoorbeeld het fiatteren van een aanvraag of mutatie. Toetsing vormt daarmee de basis van de beoordeling en kan op meerdere plaatsen in het proces een rol spelen. Binnen de toetsing component valt de uitvoer van het acceptatiekader en het genereren van de bijzondere bepalingen en de stukkenlijst. Alle drie de componenten maken gebruik van de business rule engine.
10.1
2.3.1. Business Rule Engine De business rule engine levert de functionaliteit voor het beheer van de logische regels en de evaluatie daarvan voor de verschillende componenten zoals het acceptatiekader, de stukkenlijst, bijzondere bepalingen, het risicomodel en het afspraken mechanisme.
15 van 38
Bij het beheer van een business rule wordt een boomstructuur opgebouwd van logische operatoren (<, <=, >, >=, !=, ==, EN, OF, +, -, /, * en ) en parameters, constanten en kenmerken. Met behulp van de operatoren en parameters is het mogelijk om een vergelijking te maken tussen getallen, datums en waar/niet waar. Op het hoogste niveau moet het resultaat van een beslisregel altijd waar of niet waar opleveren.
Figuur 8 - Het beheer van business rules in FORCE
De evaluatie van een business rule, aangestuurd door een specifieke component, bestaat uit een tweetal stappen: 1.
de business rule engine verzamelt alle opgevoerde parameters en kenmerken en zet deze om in de werkelijke waarden. 2. de business rule engine evalueert de beslisregel aan de hand van de achterliggende boomstructuur stap voor stap en bepaalt of er wel of niet aan de regel is voldaan (de uitkomst van de regel is waar of niet waar)
10.2
2.3.2. Acceptatiekaders In het acceptatiekader zijn alle regels vastgelegd waaraan een hypotheekaanvraag moet voldoen om de financiering te kunnen verstrekken. Iedere acceptatieregel bestaat uit een logische vergelijking tussen de parameters van de aanvraag en de ingeregelde voorwaarden (kenmerken) van het product.
Naast de logische representatie wordt aangegeven wat de uitkomst van de regel is als de aanvraag niet aan de voorwaarden voldoet. Mogelijke uitkomsten van een acceptatieregel zijn: • • • • •
goedgekeurd handmatige beoordeling voorleggen aan geldverstrekker direct afgewezen voorleggen aan veiligheidszaken
Daarnaast is het mogelijk om per regel aan te geven wat de mogelijke motivaties zijn die een gebruiker kan opgeven indien een aanvraag niet aan de regel voldoet, maar de gebruiker de uitkomst van de business rule wil “overrulen”.
Door de logische representatie is FORCE in staat om het gehele acceptatiekader volledig geautomatiseerd uit te voeren. De uitkomst van het totale acceptatiekader is gebaseerd op de zwaarste afwijzende regel waaraan de aanvraag niet voldoet. Door de opgevoerde motivaties staat de verantwoording voor de afwijzing ook direct onder elkaar. 16 van 38
10.3
2.3.3. Genereren stukkenlijst Afhankelijk van de gegevens die bij een aanvraag zijn ingevuld dient de consument bepaalde aan te tonen stukken aan te leveren. Deze aanlevering vindt plaats alvorens zijn aanvraag definitief akkoord is. Op basis van ingeregelde beslisregels is FORCE in staat om automatisch te bepalen welke specifieke stukken relevant zijn (en de consument dus aan moet leveren) en welke niet.
Mochten er gedurende het aanvraagproces bepaalde gegevens wijzigen, dan is FORCE tevens in staat om (door alle beslisregels met betrekking tot de stukkenlijst opnieuw uit te voeren) te bepalen welke stukken nog steeds relevant zijn en dus in de stukkenlijst moeten blijven staan, welke stukken niet langer relevant zijn en dus uit de stukkenlijst mogen verdwijnen en welke stukken op basis van de gewijzigde gegevens nieuw aan de stukkenlijst moeten worden toegevoegd.
10.4
2.3.4. Genereren bijzondere bepalingen Niet alle aanvragen voldoen aan alle voorwaarden die in het acceptatiekader zijn vastgelegd. Onder bepaalde aanvullende (bijzondere) voorwaarden is het echter alsnog mogelijk om het product af te sluiten. Wederom op basis van business rules is FORCE in staat om automatisch te bepalen onder welke bijzondere voorwaarden de consument het gevraagde product alsnog kan krijgen. Elke bijzondere bepaling bestaat naast een business rule uit een naam en een omschrijving die in de offerte terug moeten komen.
Analoog aan het herbepalen van de stukkenlijst is FORCE ook in het geval van bijzondere bepalingen in staat om bij het wijzigen van gegevens opnieuw te evalueren welke bijzondere bepalingen nog steeds gelden, niet langer nodig zijn of op basis van de gewijzigde gegevens juist wel nodig zijn.
10.5
2.3.5. Externe toetsingen FORCE sluit aan op alle externe toetsingen die relevant zijn voor de verwerking van financiële product aanvragen, te weten: • • • • • •
BKR; VIS; EVA; SFH; AFM; NHG.
Zie voor een beschrijving van deze toetsen paragraaf 3.1. Topicus heeft voor het automatisch interpreteren van de BKR toetsingen een dedicated component gerealiseerd. Deze component bevat onder andere: -
Volledig automatisch doortoetsen;
17 van 38
-
Automatische kredietontdubbeling;
-
Interpretatiemodule voor het automatisch interpreteren van toets resultaten en monitorberichten.
De component staat uitvoerig beschreven in het FORCE BKR whitepaper.
11
2.4. Procesbesturing Onder deze categorie vallen alle componenten die te maken hebben met het modelleren van processen in een workflow en het aansturen van specifieke acties (events). Binnen deze categorie beschikt FORCE over de volgende componenten: • • • • •
11.1
workflow manager taken events batchjobs operationele rapportages
2.4.1. Workflow Manager De workflow manager zorgt voor de modellering van processen en de aansturing van de uitvoer ervan. Een proces bestaat uit statussen en statusovergangen. De FORCE workflow manager maakt onderscheid tussen handmatige statussen (waarbij invoer van een gebruiker gewenst is) en automatische statussen (waarbij het systeem een geautomatiseerde bewerking uitvoert).
Straight-Through Processing (STP) is een voorbeeld van een proces waarbij sprake is van geautomatiseerde statusovergangen. De workflow manager pakt een nieuwe aanvraag op en zet de aanvraag telkens automatisch in de juiste vervolgstatus, waarbij de workflow manager tevens telkens op het juiste moment de juiste bewerkingen (“event”, zie §2.4.3) aanroept (bijvoorbeeld het uitvoeren van een BKR-toetsing, het toetsen van de aanvraag tegen het acceptatiekader, het genereren van een brief, et cetera). De workflow manager volgt dit procedé totdat een offerte is aangemaakt of totdat de aanvraag uit het STP proces valt.
Als de aanvraag uitvalt, dan zet de workflow manager de aanvraag naar een zogenaamde “handmatige” status. De aanvraag verschijnt dan in de werkvoorraad van een medewerker om deze handmatig te behandelen. Een medewerker of een team van behandelaars is eigenaar van een bepaalde status. De betreffende eigenaren zien de aanvraag in hun persoonlijke werkvoorraad.
Naast het direct laten uitvallen van een aanvraag is het ook mogelijk dat een gegeven later in het proces vereist is en dat de workflow manager de aanvraag vooralsnog verder via het STPproces kan verwerken. De oplossing hiervoor ligt in het takenmechanisme.
Eigenaarschap is per proces per status in te regelen door toepassing van het procesgroepconcept. In een procesgroep is vastgelegd hoe een aanvraag of overeenkomst (per status) door de organisatie (of over organisaties heen) stroomt. Vervolgens is het mogelijk om aan deze procesgroep partijen toe te kennen die deze procesgroep volgen. Op deze manier is
18 van 38
per partij onderscheid aan te brengen in het workflow proces waarmee die partij een aanvraag of overeenkomst behandelt.
11.2
2.4.2. Taken Met behulp van de takencomponent zijn taken te definieren. In de taakdefinitie is onder andere de “trigger” vastgelegd. De trigger bepaalt onder welke condities de applicatie een taak aan moet maken. De taakcomponent kent een tweetal typen triggers: 1. 2.
het bereiken van een specifieke workflowstatus de ontvangst van een document
De taakcomponent kent de gegenereerde taak toe aan een medewerker of groep medewerkers. Ook dit doet de taakcomponent op basis van de taakdefinitie. Een gegenereerde taak is vervolgens zichtbaar in de werkvoorraad van de medewerker of groep medewerkers.
Figuur 9 - Taken in de werkvoorraad
Uit de omschrijving van de gegenereerde taak blijkt welke actie een gebruiker uit moet voeren met betrekking tot de aanvraag of het ontvangen document. Aanvullend is bij een taak of proces een service level vastgelegd. Daarmee is vastgelegd binnen welk tijdsbestek de taak of het proces moet zijn afgehandeld. Tenslotte is bij de taak vastgelegd vóór welk moment in het proces deze moet zijn afgehandeld. Het niet tijdig afhandelen van de taak zorgt er voor dat het proces met betrekking tot de specifieke aanvraag blokkeert.
19 van 38
11.3
2.4.3. Events Events zijn vooraf gedefinieerde stukken logica die een bepaalde bewerking of berekening uitvoeren. Een event is te koppelen aan een workflowstatus. Op het moment dat een aanvraag door het workflowproces “stroomt” en in de betreffende status terecht komt, dan voert het systeem automatisch de bijbehorende bewerking of berekening uit. Dit kan bijvoorbeeld het uitvoeren van een BKR-toetsing, het uitvoeren van een maximale hypotheekberekening of het genereren en versturen van een offerte / contract zijn.
Aan een workflowstatus kunnen meerdere events gekoppeld zijn. Op basis van een prioritering die de gebruiker aangeeft voert de event-component de events in de juiste volgorde uit. Events zijn herbruikbaar. Indien het binnen het proces noodzakelijk is om op meerdere momenten een BKR-toets uit te voeren, dan is het mogelijk om het bijbehorende event eenvoudigweg aan meerdere workflowstatussen te koppelen.
Figuur 10 - Werking van events in FORCE workflow
11.4
2.4.4. Triggers In FORCE is het mogelijk om diverse triggers in te regelen. Hiermee is in te regelen dat een proces na een bepaalde tijd een automatische statusovergang uitvoert.Door middel van een trigger is het bijvoorbeeld mogelijk om ervoor te zorgen dat: •
de eindconsument een rappelbrief / rappelmail krijgt;
•
verlengingsrente op het juiste moment berekend wordt;
•
aanvragen automatisch vervallen als de offertegeldigheidstermijn verstrijkt.
i .
11.5
2.4.5. Operationele rapportages FORCE levert directe ondersteuning op het gebied van operationele rapportages, oftewel realtime rapportages over actuele werkvoorraden, in behandeling zijnde aanvragen en taken en eventuele overschrijdingen van SLA’s. De rapportage-component levert een vijftal soorten overzichten:
20 van 38
1.
taakrapportages: een overzicht van het actuele aantal openstaande taken, verbijzonderd naar taakdefinitie
2.
statusrapportages: een overzicht van het actuele aantal zaken dat in behandeling is, verbijzonderd naar processtatus
3.
taak-servicelevel-rapportages: een overzicht van het actuele aantal openstaande taken, verbijzonderd naar taakdefinitie en nog beschikbare behandeldagen (op basis van het servicelevel hebben verschillende taken een einddatum; via deze rapportage zijn eventuele piekbelastingen in de nabije toekomst eenvoudig af te lezen)
4.
proces servicelevel rapportage: een overzicht waarin percentueel en absoluut is af te lezen in hoeverre de proces servicelevels gehaald worden
5.
conversie rapportage: een overzicht van het aantal / percentage processen uiteindelijk tot een afgesloten product hebben geleid.
Figuur 11 - Operationele rapportage naar status
21 van 38
Figuur 12 – Operationele rapportage naar proces servicelevel
Figuur 13 - Operationele rapportage servicelevel per taak FORCE levert geen ondersteuning op het gebied van andersoortige rapportages (bijvoorbeeld strategische rapportages). Het is wel mogelijk om gegevens naar een data warehouse te exporteren om daarmee dergelijke rapportages te genereren.
12
2.5. Rekenmodules Voor een aantal processen is het noodzakelijk dat de FORCE applicatie in staat is om bepaalde berekeningen uit te voeren. Zo is er tijdens het hypotheekaanvraagproces meestal sprake van een maximale hypotheekberekening (comply en explain), tijdens het passeertraject is het van belang om de juiste netto verstrekking aan de notaris te kunnen bepalen en voor lopende overeenkomsten moet het systeem in staat zijn om de maandelijkse rente en aflossing en de vergoeding over de diverse depots te berekenen. Voor aanvragen van spaarproducten is een rendement berekening aanwezig en voor verzekeringen een premieberekening. De
22 van 38
rekenmodules gebruiken de FORCE rekenengine om de hiervoor genoemde geparameteriseerde berekeningen uit te voeren.
Voor verschillende partijen geldt dat berekeningen vaak gebruik maken van dezelfde gegevens, maar dat de berekening zelf per partij verschillend is. In dit kader is in FORCE per type berekening een geparameteriseerde berekening aanwezig. FORCE kent de volgende rekenmodules: • • • • •
fictieve executiewaardeberekening bij nieuwbouw maximale hypotheekberekening maximale overbruggingsberekening netto verstrekkingsberekening bouwdepotvergoedingsberekening
De rekenengine is binnen FORCE geïmplementeerd als losse “library” met diverse geparameteriseerde berekeningen (de rekenmodules).
13
2.6. Authenticatie & autorisatie Zoals de categorie aangeeft, beschrijft deze paragraaf twee componenten, waarmee enerzijds de authenticatie en anderzijds (op basis van authenticatie) de autorisatie is gerealiseerd.
13.1
2.6.1. Authenticatie De authenticatiecomponent regelt het verifiëren van de credentials van de gebruiker om op basis hiervan te bepalen of de gebruiker toegang heeft tot de applicatie. De authenticatiecomponent ondersteunt diverse wijzen van authenticatie: • • •
op basis van IP-whitelisting op basis van gebruikersnaam en wachtwoord op basis van certificaten of tokens, eventueel met gebruikersnaam en wachtwoord op basis van een koppeling met een active directory
Figuur 17 - Inlogpagina FORCE applicatie met security token
23 van 38
Aangezien alle FORCE applicaties webapplicaties zijn, is een medewerker niet gebonden aan één fysieke locatie om met de applicatie te werken. Met de hierboven genoemde vormen van authenticatie ondersteunt de authenticatiecomponent het plaatsonafhankelijk karakter van FORCE webapplicaties.
Voor Single Sign-On maakt FORCE gebruik van een active directory oplossing. Op het moment dat een gebruiker toegang probeert te krijgen tot de FORCE applicatie roept deze component de Active Directory aan en controleert zo de “credentials” van de gebruiker. De component matcht vervolgens de gebruikersgegevens die vastliggen in Active Directory met de gebruikersgegevens die in de FORCE applicatie bekend zijn. Als de gebruiker bekend is in de FORCE applicatie, vindt verdere autorisatie plaats op basis van de rechten en rollencomponent. Single Sign-On werkt op dit moment alleen binnen het bedrijfsnetwerk.
Bij het inloggen van de gebruiker in het hoofdsysteem wordt zijn identiteit geverifieerd vanuit de active directory. De werkelijke authenticatie vindt hiermee extern plaats. De FORCE applicatie ontvangt vanuit de Active Directory het signaal dat de gebruiker toestemming heeft om de FORCE applicatie te openen. De gebruiker hoeft hierdoor niet opnieuw op de FORCE applicatie in te loggen.
13.2
2.6.2. Rollen- & rechtenbeheer Met de autorisatiecomponent zijn alle rollen te definieren die van belang zijn voor het uitvoeren van de bedrijfsprocessen (procesrollen), voor het uitvoeren van applicatiebeheer (beheerrollen) en voor het uitvoeren van operationele rapportages (managementrollen).
De benodigde rollen zijn vrij inregelbaar. Bij het aanmaken van een rol wordt het roltype (proces, beheer, management) opgegeven. Vervolgens vindt de autorisatie voor de rol plaats door aan te geven tot welke schermen en functies gebruikers met die rol toegang hebben. Een rol vormt zo een verzameling van gerelateerde autorisaties die vervolgens aan een gebruiker zijn toe te kennen. Uiteraard kan één gebruiker meerdere rollen vervullen. Het toekennen van een rol aan een gebruiker kan in FORCE. De organisatie kan er ook voor kiezen de koppeling tussen de gebruiker en de rol in active directory vast te leggen.
Op het moment dat er kleine verschillen zijn in de autorisaties, dan ontstaan er verschillende rollen met ongeveer hetzelfde doel. Deze rollen zijn gegroepeerd binnen één hoofdrol. Vanuit deze hoofdrol is vervolgens de relatie te leggen met de workflow. Per status is aangegeven welke hoofdrol eigenaar is van deze status. Deze koppeling zorgt ervoor dat alleen de geautoriseerde personen de aanvragen met de juiste status in hun werkvoorraad zien.
14
2.7. Product & pricing Onder het thema product & pricing vallen alle componenten die te maken hebben met de configuratie en administratie van de financiële producten en de bijbehorende prijsbepaling van deze producten.
24 van 38
14.1
2.7.1. Productmodel De productdefinitie component ondersteunt het definiëren van de verschillende financiële producten. Door de producten te groeperen in een boomstructuur is het mogelijk om de producteigenschappen te hergebruiken over verschillende groepen producten. FORCE bevat een aantal generieke basisproducten, op basis waarvan financiële instelling zelf specifieke producten kan inregelen.
Figuur 18 - Beheren van producten vanuit een boomstructuur
14.2
2.7.2. Provisiemodel Het provisiemodel bevat alle geldstromen met betrekking tot kosten en provisie. Vanuit een hoofdstroom is vastgelegd voor welk bedragsoort (bijvoorbeeld bemiddellingsprovisie) er geld stroomt van partijtype A (bijvoorbeeld een servicer) naar partijtype B (bijvoorbeeld een tussenpersoon). De bedragsoorten zijn vrij te definiëren en voor partijtype A en B is ieder een relevante type partij te kiezen.
Het provisiemodel is gekoppeld aan het productmodel; nadat een hoofdstroom is ingeregeld zijn de specifieke provisiestromen (een percentage of een vast bedrag) in te regelen. Provisiestromen zijn op dezelfde definitieniveau’s in te regelen als de overige producteigenschappen (zie de vorige paragraaf). Hierdoor is een provisiestroom te verbijzonderen voor een label, productlijn of product.
14.3
2.7.3. Rentemodel Het rentemodel levert ondersteuning bij het definieren van renteproducten en renteinrichtingen en bij het beheer van tarieven. In een renteproduct zijn de verschillende renteeigenschappen vastgelegd, waaronder o.a.: 25 van 38
•
de contractstermijn
•
de rentevorm (vast of variabel)
•
de renteherzieningstermijn
•
de rentebedenktijd (duur, vooraf of achteraf)
•
een eventuele buffer of limiet
De renteinrichting-component fungeert binnen de rentemodel-component als “spin in het web”. Allereerst is in de renteinrichting vastgelegd welke renteproducten zijn toegestaan voor specifieke productlijnen en producten. Daarnaast specificeert een renteinrichting voor welke productlijnen en producten dezelfde risicoopslagen en tarief-structuren gelden. Tot slot is in een renteinrichting vastgelegd voor welke rentebepalingsberekeningen en voor welke regelingen en mutaties de tarieven gelden.
Het beheer van tarieven vindt vervolgens plaats per renteinrichting. Het beheer van de rentetarieven werkt op basis van het vier ogen-principe (middels mutatiegroepen) en is geversioneerd op basis van datum. In het geval dat voor een product voor een bepaalde periode geen daadwerkelijke tarieven zijn ingeregeld maar het wel mogelijk moet zijn om een tarief af te geven is het mogelijk om als tarief “onbekend” in te regelen.
FORCE kan de rentetarieven exporteren naar andere systemen (bijvoorbeeld naar backoffice systemen of de website). Andere systemen kunnen via een webservice de meest recente tarieven ophalen (pull), ook kan FORCE de rente opsturen zodra deze wijzigt (push).
14.4
2.7.4. Risicomodel Met het risicomodel kan de financiele instelling risk based pricing toepassen. Het risicomodel maakt gebruik van de business rule engine voor het vaststellen van het risico dat gepaard gaat met de aanvraag. De risicoregels leiden tot een score, op basis van deze score bepaalt FORCE de bijbehorende risicoklasse. De benodigde risicoklassen en het bijbehorende scorebereik zijn volledig vrij in te richten. Dit geldt eveneens voor de aan de risicoklasse gekoppelde rente opslag.
Het risicomodel kan eenvoudig worden ingezet om risico’s te bepalen voor ander doeleinden dan de rentebepaling. Alleen de relatie tussen het model en het andere doel moet dan worden uitgewerkt.
Het is uiteraard ook mogelijk om in aanvulling op of ter vervanging van het FORCE risicomodel gebruik te maken van andere risicomodules. Koppelingen met interne danwel externe risicomodules zijn beschreven in hoofdstuk 3, “Koppelingen met andere systemen”.
14.5
2.7.5. Kenmerken Het kenmerkenmechanisme specificeert alle enkelvoudige producteigenschappen (kenmerken) en legt de ingeregelde waarde vast op ieder in paragraaf 2.8.1 genoemd verticaal niveau. Door bijvoorbeeld voor de productlijn “budget” het kenmerk “maximale hypotheek” de waarde 26 van 38
“400.000” op te voeren is vervolgens in een business rule of in een applicatiescherm af te dwingen dat de totale hoofdsom van een aanvraag voor een budgethypotheek niet groter mag zijn dan vier ton. Op de kenmerkwaarden is versionering van toepassing: instelbaar is op welke datum welke waarde geldt.
De component werkt op basis van de op het laagste niveau ingeregelde kenmerkwaarde; als een kenmerk zowel op het productlijn-niveau als op het product-niveau een kenmerkwaarde heeft, dan geldt de waarde op het product-niveau.
Door het gebruik van het kenmerkenmechanisme is het mogelijk om: •
berekeningen en andere applicatie-logica te parametriseren
•
de workflow te sturen
•
beperking van beschikbare keuzes in de aanvraag of een ander invoerproces
•
kenmerkwaarden te gebruiken in business rules en daarmee in acceptatiekaders en risicomodellen
14.6
2.7.6. Afspraken en modules Naast de standaard productdefinitie van kenmerken, rente en provisie is het wenselijk om in bepaalde situaties en/of voor een specifieke partij aanvullende bijzonderheden of afwijkingen vast te kunnen leggen. Te denken valt bijvoorbeeld aan een personeelskorting of een tijdelijk renteverlaging. Dit kan met behulp van het afsprakenmechanisme, waarmee tevens modulaire hypotheken zijn ondersteund (een module is immers ook te beschouwen als een afwijking op een standaard hypotheekproduct).
Een afspraak bestaat uit afspraakdelen. Een afspraakdeel definieert een afwijkende kenmerkwaarde, een afwijkende provisiestroom of een afwijkende renteopslag. Door afspraakdelen aan een afspraak te koppelen en aan te geven voor welke specifieke partijen en producten de afspraak geldig is, is de afspraak inhoudelijk gedefinieerd. Tot slot is door middel van een aan de afspraak gekoppelde business rule vastgelegd onder welke condities de afspraak geldig is.
Tijdens het aanvraagproces bepaalt de afspraken-component op basis van de ingeregelde afspraken welke afspraken de applicatie automatisch moet koppelen aan de in de aanvraag gekozen producten. Aanvullend is het mogelijk om handmatige afspraken op te voeren.
15
2.8. Gegevensintegriteit De categorie “Gegevensintegriteit” bevat alle FORCE componenten die bijdragen aan het waarborgen van de integriteit van alle gegevens die met behulp van de webapplicatie zijn vastgelegd.
27 van 38
15.1
2.8.1. Correctheid & compleetheid Bij het uitvoeren van bedrijfsprocessen (bijvoorbeeld het verwerken van een nieuwe aanvraag) kan sprake zijn van invoer van de aanvraag door een gebruiker via applicatieschermen, maar ook van invoer van de aanvraag via het inlezen van een HDN-bericht of een bericht van de website en de daarop volgende verdere verwerking via een STP-proces. In beide gevallen is het van belang om de ingevoerde gegevens te controleren. Een aanvraag moet voldoen (en moet gedurende het afhandelingsproces ook blijven voldoen) aan alle geldende controles.
De verschillende controles zijn centraal vastgelegd in de correctheid & compleetheid component. Zowel de applicatieschermen als een STP-proces kan de component aanroepen en daarmee de controles uitvoeren. Controles zijn te combineren in workflow events zodat een “set” van controles vanuit diverse statusovergangen binnen een proces is aan te roepen.
15.2
2.8.2. Audittrail De audittrail component registreert alle gegevensmutaties (dat wil zeggen: het opslaan van nieuwe gegevens, het wijzigen van gegevens en het verwijderen van gegevens) die een gebruiker of een systeem uitvoert. Het maakt hierbij niet uit of het gaat om gegevens van een aanvraag of gegevens die een functioneel beheerder aanpast: van elke wijziging wordt vastgelegd wat de wijziging betreft, wanneer het plaatsvond en wie het deed. Registratie vindt plaats in een separate database. Alleen geautoriseerde gebruikers hebben inzage in deze gegevens.
Figuur 19 - Globale werking van de FORCE audittrail component
De audittrail component is generiek opgezet; voor elk bedrijfsproces (dus ook voor een eventueel nieuw bedrijfsproces) dat gebruik dient te maken van de audittrail moet éénmalig op
28 van 38
één plek de audittrail component worden aangeroepen, waarna de component automatisch alle gegevensmutaties voor dat bedrijfsproces registreert.
16
2.9. Dossiermanagement De categorie “Dossiermanagement” bevat alle FORCE componenten die gerelateerd zijn aan het genereren en beheren van diverse documenten gerelateerd aan de ondersteunde financiële processen. Onder deze categorie valt het aansturen van documentgeneratie (de aansturing van een output management systeem), maar ook het ontsluiten van het archief (de aansturing van een document management systeem) en de beoordeling van documenten (het inboeken en beoordelen van ontvangen stukken).
16.1
2.9.1. Output management Het FORCE framework bevat een component om diverse outputdocumenten (zoals brieven, emails en faxen) te genereren. Daar waar een partij reeds beschikt over een eigen output management systeem is het ook mogelijk om vanuit FORCE met een dergelijk systeem te koppelen. In dit laatste geval vindt de generatie van output plaats in het output management systeem, maar de aansturing van het output management systeem gebeurt vanuit de FORCE output management component.
In de output management component zijn de volgende zaken vastgelegd: • • • • • •
de documenttemplates om de output mee te genereren welke documenten een gebruiker handmatig aan mag maken onder welke condities het systeem een bepaald document automatisch aan mag maken (dit gebeurt op basis van business rules) onder welke condities het systeem een bepaald document automatisch mag versturen (wederom op basis van business rules) welk template in het output management systeem moet worden gebruikt voor het genereren van het document welke (XML) gegevensset moet worden gevuld
Door events te definieren die de output management aansturingscomponent aanroepen en deze events in de workflow manager aan een bepaalde status te koppelen is het mogelijk om binnen een proces volledig automatisch de benodigde output te genereren en zelfs te versturen.
De module is generiek opgezet, zodat het toevoegen van nieuwe documenten slechts een minimale impact heeft; indien FORCE nieuwe soorten documenten moeten kunnen genereren, dan is slechts een nieuw berichttemplate in het output management tool benodigd.
16.2
2.9.2. Archiefbeheer Het FORCE framework bevat geen eigen document management systeem (DMS) component. Voor de opslag en het beheer van allerhande binnenkomende en uitgaande documenten maakt FORCE doorgaans gebruik van opslag op een filesystem of van een koppeling met een specifiek voor dat doel aanwezig systeem. Het FORCE framework regelt wel de aansturing van het DMS. 29 van 38
Dit gebeurt via de archiefbeheercomponent.
De archiefbeheercomponent draagt zorg voor: •
• •
17
het vastleggen van welke documentsoorten voor een bepaalde partij (tussenpersoon, packager, whitelabel, servicer, geldverstrekker) zichtbaar zijn bij het tonen van het archief in de applicatie de daadwerkelijke ontsluiting van alle gearchiveerde documenten bij een specifieke aanvraag of een specifieke overeenkomst het kunnen inboeken en beoordelen van binnengekomen stukken in het kader van een hypotheekaanvraag (oftewel het relateren van de stukkenlijst van aan te tonen stukken aan de daadwerkelijk ontvangen stukken)
2.10. Financiële afhandeling De boekhouding zelf en de bijbehorende financiële afhandeling van in- en excasso’s valt onder de verantwoordelijkheid van bestaande financiële pakketten. De FORCE applicatie stuurt deze financiële afhandeling aan. Naast het beheer van de betalingscondities en de opbouw van de vervalkalender zijn losse boekingen mogelijk vanuit de verschillende bedrijfsprocessen. Bovenop een generieke functie die de verschillende boekingen aanmaakt zijn processpecifieke uitbreidingen hier op mogelijk. Deze zogenaamde betalingsstekkers zetten de vanuit een proces bepaalde specifieke geldwaarden om in de juiste boekingen. FORCE zet vervolgens de klaargezette boekingen over naar het boekhoudpakket.
17.1
2.10.1. Boekingen Met behulp van de boekingencomponent houdt FORCE iedere financiële mutatie bij. Per boeking houdt FORCE de volgende zaken bij: • • •
het product waar de mutatie betrekking op heeft (bijvoorbeeld een leningdeel) de bij de boeking betrokken partijen (debiteur en crediteur) de vervaldatum van de mutatie
De verschillende bedrijfsprocessen “vullen” het overzicht van de boekingen. De omzetting van de berekende waarden in de bedrijfsprocessen naar de boekingen vindt plaats met behulp van zoganaamde betalingsstekkers. Deze zijn verder beschreven in paragraaf 2.11.3.
Vanuit het bedrijfsproces zet de component de boekingen vooraf klaar en koppelt deze aan het lopende contract voor de latere financiële afhandeling. Op basis van de vervaldatum bij de boekingen bepaalt de component op welk moment de applicatie de geplande boekingen moet overzetten naar het financiële pakket.
17.2
2.10.2. Betalingscondities Voor de omzetting van de berekende waarden in boekingen en het omzetten van de boekingen naar het financiële systeem maakt FORCE gebruik van betalingscondities. In de betalingscondities liggen per partij met een financiële administratie vast welke grootboekrekeningen de financiële afhandelingscomponenten moeten gebruiken voor een 30 van 38
boeking van een bepaalde bedragsoort. Aanvullend ligt in deze component bijvoorbeeld ook vast wat de te gebruiken betalingswijze is.
De betalingscondities zijn ingeregeld op een definitieniveau, zie ook paragraaf2.8.1. Door de relatie met de productdefinitie is het mogelijk om voor verschillende partijen (met een financiële administratie) een andere financiële afhandeling in te regelen met behulp van de betalingscondities. Naast een koppeling aan de productdefinitie is het ook mogelijk om een betalingsconditie aan een productinstantie te koppelen. Deze koppeling zorgt ervoor dat voor een individueel afgesloten product een afwijkende financiële afhandeling in te regelen is.
17.3
2.10.3. Betalingsstekkers De betalingsstekkers zorgen voor de omzetting van een, vanuit een bedrijfsproces berekende, waarde naar één of meer boekingen. De betalingstekker component bevat een generiek deel waarmee het oppakken van de betalingscondities en de omzetten naar de boekingen structuur is uitgewerkt. Bovenop het generieke deel is daarnaast een specifieke stekker aanwezig die zorgt voor de omzetting voor een bepaald bedrijfsproces.
Een voorbeeld van een betalingsstekker is de omzetting van de berekende rente en aflossing naar de bijbehorende boekingen. Op basis van de aflossingsvorm is het juiste maandbedrag aan rente en aflossing bepaald. De rente- en aflossingstekker zet dit maandbedrag vervolgens om naar de juiste boekingen. Het eindresultaat is een serie boekingen waarbij voor iedere termijn de vervaldatum is vastgesteld.
17.4
2.10.4. Vervalkalender De vervalkalender bestaat uit een weergave van alle geplande termijnbedragen met betrekking tot een overeenkomst. Vanuit de weergave is het mogelijk om te zoeken naar specifieke boekingen bij een bepaalde bedragsoort of naar een serie boekingen die binnen een bepaalde termijn zullen vervallen. De filtering van de vervalkalender helpt tevens om te bepalen welke termijnbedragen de applicatie via een boekingenbatch door moet geven aan de financiële applicatie.
18
2.11. Contractbeheer Onder de categorie “Contractbeheer” vallen alle componenten die zorg dragen voor het beheer van afgesloten contracten. Hieronder valt het beheer van overeenkomsten en het daaraan gerelateerde versiebeheer (van belang op het moment dat er een wijziging op een lopend contract wordt doorgevoerd), de administratie van aan het contract verbonden zekerheden en de ondersteuning van bijzonder beheer.
31 van 38
18.1
2.11.1. Overeenkomstenbeheer Deze component bevat de overkoepelende functionaliteit die nodig is voor het beheren van overeenkomsten vanaf het moment dat een aanvraag wordt omgezet in een contract. De component biedt ondersteuning op de volgende punten: •
•
•
18.2
het creëren van een dossier op het moment dat een aanvraag een contract wordt (danwel het toevoegen van het contract aan een bestaand dossier indien de contractant reeds andere contracten heeft lopen) het ontsluiten van algemene gegevens met betrekking tot de overeenkomst (denk daarbij aan het inzien van NAW-gegevens van de contractant, productgegevens van het afgenomen product, algemene gegevens van het onderpand, et cetera) het zoeken naar contracten die aan bepaalde zoekcriteria (zoals contractant- en productgegevens) voldoen
2.11.2. Versiebeheer Gedurende de totale levensduur van een overeenkomst is het mogelijk dat er wijzigingen op de overeenkomst moeten worden doorgevoerd. Dit variëert van financiële wijzigingen (bijvoorbeeld aflossing, omzetting, wijziging van het geleende bedrag, wijziging van de rente) tot inhoudelijke wijzigingen (zoals het verwijderen of toevoegen van een contractant, het wijzigen van persoonsgegevens of gegevens van een zekerheid).
Het is daarbij van wezenlijk belang dat gedurende de periode dat de wijziging wordt doorgevoerd, maar nog niet is gefinaliseerd, de lopende overeenkomst hier geen hinder van ondervindt. Het is bijvoorbeeld niet de bedoeling dat de rente bij een lopende overeenkomst al gewijzigd wordt terwijl het rentewijzigingsproces nog niet is afgerond. Hiervoor is versiebeheer op contracten benodigd.
Figuur 20 – Gebruik van versies voor het doorvoeren van wijzigingen
32 van 38
In dit kader beschikt FORCE over een versiebeheercomponent die in staat is om nieuwe versies van een overeenkomst te genereren. De huidige versie van de overeenkomst (in FORCE de “contractversie” genaamd) is de actieve versie, waarop alle acties (bijvoorbeeld rente en aflossing) volgens het reguliere schema plaatsvinden. Indien een wijzigingsproces op een overeenkomst start, creëert deze component eerst een nieuwe, inactieve versie van de overeenkomst. Binnen FORCE staat deze versie bekend als de “procesversie”. Aan deze versie zijn alle relevante overeenkomstgegevens gekoppeld. Op de procesversie voert de gebruiker alle benodigde wijzigingen door. Op het moment dat het wijzigingsproces is afgerond zet de versiebeheer-component de tot dan toe nog actieve contractversie op inactief en wordt de procesversie waarin de wijziging is doorgevoerd omgezet naar de actieve contractversie van de overeenkomst.
18.3
2.11.3. Zekerheden administratie Aan een contract liggen doorgaans één of meerdere zekerheden ten grondslag, welke kort na het afsluiten van de definitieve overeenkomst moeten worden ontvangen en geadministreerd. Hiervoor beschikt FORCE over een eigen zekerhedenadministratie. De component draagt zorg voor: • • •
•
18.4
het automatisch bepalen (met behulp van business rules) welke zekerheden nodig zijn bij het betreffende contract het binnenboeken en beoordelen van ontvangen zekerheden de aansturing van het takenmechanisme teneinde te rappelleren over incorrecte of nog ontbrekende stukken; ook is het mogelijk om via een koppeling met output management direct te rappelleren naar externe partijen (zoals de notaris) het royeren en vrijgeven van zekerheden op basis van royements-criteria (indien bijvoorbeeld de waarde van een asset wijzigt, als de zekerheid een bepaalde status bereikt, indien een vooraf ingestelde periode verstrijkt of indien sprake is van gehele of gedeeltelijke aflossing)
2.11.4. Bijzonder beheer Op het moment dat binnen de portefeuille één of meer defaults optreedt belandt het bijbehorende contract in bijzonder beheer. Op het moment dat dit gebeurt, stopt het reguliere proces en neemt de bijzonder beheer component van FORCE het contract over. Concreet zorgt deze component voor de volgende zaken: •
• • •
het verzorgen van de gegevensuitwisseling tussen en aansturing van het bijzonder beheerpakket en de financiële administratie (het pauzeren van alle reguliere boekingen in de vervalkalender, het blokkeren van uitbetalingen uit depots, et cetera) de aansturing van output management voor communicatie richting de contractant(en) in de vorm van bijvoorbeeld aanmaningsbrieven het initiëren van rapportage richting betrokken partijen (geldverstrekker, NHG, BKR) het opstellen van betaalafspraken en regelingen en het verwerken hiervan in de financiële administratie op het moment dat het contract weer uit bijzonder beheer stroomt (het opnieuw samenstellen van de vervalkalender, het deblokkeren van de depots, et cetera)
33 van 38
Figuur 21 - Afhandeling van defaults via bijzonder beheer
Binnen het bijzonder beheer proces is een belangrijke rol weggelegd voor de FORCE BKR component. Dit geldt voor de ondersteuning bij contracten die in bijzonder beheer zijn en daarnaast ook voor het voorkomen van het optreden van defaults. Door automatische monitoring van de contractant bij BKR zijn verhoogde risico’s van het optreden van defaults te signaleren.
18.5
2.11.5. Securitisatie Securitisatie behelst het samenvoegen van verschillende contracten uit de eigen portefeuille om deze vervolgens als effecten verhandelen door middel van een SPV. De FORCE securitisatie component biedt ondersteuning op de volgende onderdelen: •
•
•
•
• • •
het uitvoeren van alle in- en uitstroomcriteria met behulp van business rules; indien een contract voldoet aan alle opgestelde regels dan kan deze in- of uitstromen in de specifieke administratie de selectie van de te securitiseren contracten (onder andere met behulp van de beoordeling door een rating agency en de daarbij uitgevoerde onderverdeling in risicoklassen of “buckets”) het uitvoeren van de securitisatie (waaronder het aanpassen van de economische eigenaar, het verwerken van de balans en de aansturing van het aanmaken van alle benodigde boekingen in de financiële administratie); hier vindt doorgaans een sterke wisselwerking plaats tussen de securitisatiecomponent en de “Financiële afhandeling” componenten het opleveren van de benodigde overzichten met betrekking tot de securitisatie (het overzicht van alle gesecuritiseerde contracten en de bijbehorende balanspositie en de openingsbalans vanuit de financiële administratie) het correctieproces in het geval van afkeuringen (bijvoorbeeld vanwege het optreden van defaults), waarbij ook een algehele “roll-back” mogelijk is het finaliseren van de securitisatie, wederom met de mogelijkheid tot een algehele “rollback” het aanleveren van informatie voor rapportages en audits
34 van 38
3.
Koppelingen met andere systemen Om verschillende bedrijfsprocessen optimaal te kunnen ondersteunen, beschikt FORCE over diverse koppelingen met systemen van derde partijen. Deze systemen verzorgen veelal een zeer specifiek deel van het proces of stellen gegevens beschikbaar waar FORCE (en de organisatie waar de FORCE applicatie voor is gerealiseerd) zelf niet de beschikking over heeft. Daar waar mogelijk koppelt FORCE met externe systemen op basis van koppelstandaarden zoals bijvoorbeeld SOAP / XML webservices.
Koppelingen met andere systemen vallen uiteen in koppelingen met externe systemen en koppelingen met interne systemen. Onder interne systemen vallen systemen die eigendom zijn van de partij die ook gebruik maakt van de FORCE applicatie en die binnen het domein van die partij draaien. Het zijn vaak systemen die een centrale functie vervullen binnen de organisatie (bijvoorbeeld het pakket dat gebruikt wordt voor de financiële administratie) of systemen met een zeer specifieke functie (bijvoorbeeld een verzekerings black box). Externe systemen zijn systemen die buiten het domein van FORCE vallen en die in eigendom en beheer zijn van andere partijen. Denk hierbij aan BKR, NHG en ECH.
De koppeling met systemen is binnen FORCE beschikbaar in de vorm van workflow events. Daarmee is het inregelbaar op welke momenten in het proces het systeem een bepaalde koppeling aan moet roepen. Op deze manier is het bijvoorbeeld in het hypotheekaanvraagproces mogelijk om op verschillende momenten automatisch een BKR-toets uit te voeren.
Indien er op basis van de door een systeem geretourneerde gegevens nog een specifieke afhandeling nodig is, dan dient dit nog wel in een processpecifiek stuk applicatielogica te worden gerealiseerd. Zo kan uit een BKR-toets bijvoorbeeld terugkomen dat een consument een A-notering heeft. Als dit in het proces betekent dat de consument eerst zijn krediet af moet lossen alvorens hij in aanmerking komt voor een hypotheek, dan is hier specifieke applicatielogica voor nodig. De koppeling met BKR en het workflow event dwingen dit niet af.
19
3.1. Koppelingen met externe systemen Het FORCE framework bevat koppelingen met de volgende externe systemen: •
AFM Voor de AFM toetsing maakt FORCE gebruik van een op zichzelf staande AFM service. De AFM service downloadt dagelijks de laatste versie van het AFM register. Vanuit de verschillende op FORCE gebasserde applicaties wordt vervolgens met behulp van een webservice call deze service aangeroepen om de machtiging voor de verstrekking van een product door een packager of tussenpersoon te toetsen.
•
BKR / LIS Voor hypotheekaanvragen controleert het systeem de lopende kredieten van een consument. De toetsing retourneert de hoogte en de status van de verschillende lopende kredieten terug. Een voorbeeld van een status is of de consument een betalingsachterstand heeft. De resultaten van een BKR-toets dienen als input voor de
35 van 38
NHG volledigheidstoets en voor het kunnen uitvoeren van het acceptatiekader. Het FORCE framework maakt gebruik van de LogiLink software van Centric voor de BKR toetsing. •
ECH Vanuit het FORCE framework wordt een koppeling gerealiseerd met de ECH webservice. Bovenop deze technische koppeling moet dan uiteraard nog een applicatie specifieke invulling worden gerealiseerd met betrekking tot de verwerking van de gegevens in de specifieke processen.
•
EVA / VIS In het kader van fraudetoetsing en –preventie beschikt FORCE over een koppeling met EVA en VIS, waarmee het mogelijk is om respectievelijk personen en legitimatiebewijzen te toetsen tegen de landelijke registratielijsten van fraude bij BKR.
•
Externe risicomodule Via een externe risicomodule (bijvoorbeeld de Stater Risk Module) is het mogelijk om op basis van diverse aanvraaggegevens te bepalen in welke risicocategorie een aanvraag valt. Op basis van het resultaat van de aanroep van deze koppeling kan de gebruiker of het systeem een risico-opslag hanteren voor de aanvraag. Het is mogelijk om koppelingen met één of meerdere externe risicomodules te gebruiken in aanvulling op of ter vervanging van de FORCE risicomodule.
•
HDN Veel partijen maken gebruik van het Hypotheken Data Netwerk om diverse HDNberichten uit te wisselen. In dit kader beschikt FORCE over een koppeling met dit netwerk teneinde nieuwe aanvragen te ontvangen en status- en offerteberichten aan een aanvragende partij te retourneren.
•
NBWO De koppeling met NBWO (Nederlands Bureau Waardebepaling Onroerende zaken) omvat het bepalen van de waarde van een onderpand op basis van de geavanceerde rekenmodellen die NBWO hanteert, gevoed met data vanuit onder andere het Kadaster, gegevens vanuit de WOZ en gegevens over eerdere verkopen van het onderpand.
•
NHG De koppeling met NHG omvat enerzijds de aanroep van de NHG inkomenstoets en NHG volledigheidstoets die voor het aanvraagproces van belang zijn en anderzijds de aanroep van NHG RADAR om, nadat een aanvraag passeert, een NHG-post aan te melden bij NHG.
•
Postcodeservice De koppeling met de postcodeservice maakt het mogelijk om op basis van een postcode en huisnummer automatisch de bijbehorende straat en plaats op te halen. Dit vereenvoudigt en versnelt de invoer van adresgegevens.
•
SFH Om te controleren of er bij een hypotheekaanvraag (of ander proces, bijvoorbeeld de afhandeling van een bouwdepot declaratie) sprake is van fraude, is via deze FORCE koppeling het centrale fraude-register van Stichting Fraudebestrijding Hypotheken te raadplegen.
36 van 38
20
3.2. Koppelingen met interne systemen Bij veel FORCE implementaties is FORCE gekoppeld aan één of meerdere van de volgende interne systemen: •
Backoffice systemen FORCE is procesmatig dusdanig ingericht dat het gegevens van bestaande contracten kan opvragen en de gegevens van nieuw afgesloten producten of gemuteerde producten kan opsturen naar de backoffice. Voor kent hiervoor een aantal standaard interfaces. Afhankelijk van de interactiemogelijkheden van het backoffice systeem kunnen aan FORCE interfaces toegevoegd worden danwel aangepast worden. Topicus adviseert het inzetten van een service bus, welke zonodig de translatie van FORCE naar het backoffice systeem kan uitvoeren.
•
Active Directory Door te koppelen met een Active Directory is invulling gegeven aan de authenticatie van gebruikers en tevens het Single Sign-On principe. Gebruikerscredentials liggen vast in de Active Directory en FORCE leest deze uit om te bepalen of een gebruiker toegang heeft tot de applicatie. De verdere autorisatie van een geauthenticeerde gebruiker vindt volledig binnen FORCE plaats.
•
Adviessoftware Diverse partijen maken gebruik van adviessoftware voor het adviseren van eindconsumenten. Denk hierbij aan pakketten als AfinHyp of Efdécé. Het FORCE framework is in staat om met dergelijke systemen te koppelen, gegevens aan dergelijke systemen aan te leveren en een uitgebracht advies te verwerken en te presenteren aan de gebruiker.
•
Data Warehouse Daar waar FORCE een component bevat voor het genereren van operationele managementrapportages, vindt strategische rapportage plaats vanuit een Data Warehouse. Het DWH prikt direct in op de database en onttrekt hieraan alle gegevens die nodig zijn voor de strategische rapportages.
•
Document management Hierin vindt de archivering van alle ontvangen en verzonden documenten plaats. De koppeling vanuit FORCE is gebaseerd op een SOAP / XML webservice, waarmee het archief is ontsloten. Via de koppeling is het mogelijk om van een aanvraag een lijst van alle gearchiveerde documenten op te vragen en om een specifiek gearchiveerd document te openen.
•
Output management In het outpunt management systeem vindt de daadwerkelijke generatie van documenten (brieven, e-mails, faxen, et cetera) plaats. De aansturing van het output management systeem gebeurt vanuit een FORCE component. De koppeling is gebaseerd op de uitwisseling van XML-berichten via een SOAP webservice.
•
Relatiebeheersysteem Aangezien de gegevens van verschillende ketenpartners door meerdere interne systemen worden gebruikt wordt in de regel gebruik gemaakt van een
37 van 38
relatiebeheersysteem. In dit systeem zijn alle partijen vastgelegd waarmee een financiële organisatie samenwerkt, waaronder geldverstrekkers, verzekeraars, tussenpersonen, packagers, notarissen en taxateurs. Via de koppeling is het mogelijk om naar relaties te zoeken en om de gegevens van een gevonden relatie op te halen en te gebruiken in het bijvoorbeeld het aanvraagproces of een specifieke beheerfunctie. •
Financiële administratie De gehele financiële administratie en het daadwerkelijk verwerken van boekingen en uitvoeren van alle in- en excasso’s vindt in de regel plaats in een financiëel systeem (bijvoorbeeld CODA of Exact). Doorgaans hebben organisaties reeds de beschikking over een dergelijk gespecialiseerd systeem waar FORCE vervolgens mee koppelt. FORCE regelt de aansturing (op basis van de mutaties die voortkomen uit de verschillende bedrijfsprocessen en de geplande termijnen bij een lopend contract) van een dergelijk pakket en de uitvoering vindt vervolgens in het pakket zelf plaats.
•
Bijzonder beheersysteem Naast een systeem voor de reguliere financiële administratie beschikken veel organisaties ook over een apart systeem voor de afhandeling van posten die in default geraken. In een bijzonder beheer systeem vindt registratie van betalingsachterstanden plaats en kunnen betalingsafspraken worden aangegeven die met een contractant zijn gemaakt.
•
Interne risicomodules Indien reeds een interne risicomodule aanwezig is, kan FORCE hier mee koppelen. Op basis van diverse aanvraaggegevens is hiermee te bepalen in welke risicocategorie een aanvraag valt. Op basis van het resultaat van de aanroep van deze koppeling kan de gebruiker of het systeem een risico-opslag hanteren voor de aanvraag. Het is mogelijk om koppelingen met één of meerdere interne risicomodules te gebruiken in aanvulling op of ter vervanging van de FORCE risicomodule.
•
Verzekerings black boxes Aan een hypotheek is veelal een verzekering gekoppeld. Voor een aantal verzekeraars is een black box beschikbaar, waarmee op basis van diverse inputgegevens een verzekeringspremie is te berekenen.
38 van 38
