FORCE Framework - Topicus Finance

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