Topicus FORCE Framework · 2020. 2. 3. · Topicus – Singel 25, 7411 HW, Deventer – tel. 0570-...

Topicus FORCE Framework

Whitepaper

Topicus – Singel 25, 7411 HW, Deventer – tel. 0570- 767 318 - www.topicusfinance.nl 2 van 40

Inhoudsopgave

1.1. Zoveel mogelijk geautomatiseerde afhandeling van processen (STP) ..................... 4

1.2. Korte time-to-market voor de introductie van nieuwe producten en processen .... 5

1.3. Distributie naar ketenpartners via het “common workspace” concept .................. 5

1.4. Herbruikbaarheid van componenten, ongeacht het bedrijfsproces ........................ 6

1.5. Directe link met de eindconsument ......................................................................... 7

1.6. De executie van campagnes is onderdeel van de front- en midoffice ..................... 8

1.7. Mid- en backoffice als één applicatie ....................................................................... 8

2.1. 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. Campagne management ......................................................................................... 22

2.5.1. Projectmarketing .......................................................................................................... 22

2.5.2. Procesmarketing ........................................................................................................... 23

2.6. Rekenmodules ........................................................................................................ 24

2.7. Authenticatie & autorisatie .................................................................................... 25

2.7.1. Authenticatie ................................................................................................................ 25

2.7.2. Rollen- & rechtenbeheer .............................................................................................. 26

2.8. Product & pricing .................................................................................................... 26

2.8.1. Productmodel ............................................................................................................... 26

2.8.2. Provisiemodel ............................................................................................................... 27

2.8.3. Rentemodel................................................................................................................... 27

2.8.4. Risicomodel ................................................................................................................... 28

2.8.5. Kenmerken .................................................................................................................... 28

2.8.6. Afspraken en modules .................................................................................................. 29


2.9. Gegevensintegriteit ................................................................................................ 29

2.9.1. Correctheid & compleetheid ........................................................................................ 29

2.9.2. Audittrail ....................................................................................................................... 30

2.10. Dossiermanagement ............................................................................................. 31

2.10.1. Output management .................................................................................................. 31

2.10.2. Archiefbeheer ............................................................................................................. 31

2.11. Financiële afhandeling .......................................................................................... 32

2.11.1. Boekingen ................................................................................................................... 32

2.11.2. Betalingscondities ....................................................................................................... 32

2.11.3. Betalingsstekkers ........................................................................................................ 33

2.11.4. Vervalkalender ............................................................................................................ 33

2.12. Contractbeheer ..................................................................................................... 33

2.12.1. Overeenkomstenbeheer ............................................................................................. 33

2.12.2. Versiebeheer ............................................................................................................... 34

2.12.3. Zekerheden administratie ........................................................................................... 35

2.12.4. Bijzonder beheer ......................................................................................................... 35

2.12.5. Securitisatie ................................................................................................................ 36

3.1. Koppelingen met externe systemen ....................................................................... 37

3.2. Koppelingen met interne systemen........................................................................ 39


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. zoveel mogelijk geautomatiseerde afhandeling van processen (STP)

2. korte time-to-market voor de introductie van nieuwe producten en processen

3. distributie naar andere partijen is mogelijk via het “common workspace” concept

4. componenten zijn herbruikbaar, ongeacht het te ondersteunen bedrijfsproces

5. directe link met de eindconsument (customer self service)

6. de executie van campagnes is onderdeel van de front- en midoffice 7. mid- en backoffice zijn te ondersteunen middels één applicatie

1 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.


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 producten 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


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.


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).


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 project-

en 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


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.


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.


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.


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)

Corporate website formulier Label x Label y Label z

FORCE . Webparts

SOAP XML

Intranet

FORCE

Xml asynchroon

Webpart

Webpart

Webpart

XML Gateway

Inlezen procesgegevens

Productkenmerken


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. door ontsluiting van een met FORCE gerealiseerde applicatie aan diverse partijen

2. 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


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


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.


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.


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;


- 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:

• workflow manager

• taken

• events

• batchjobs

• operationele rapportages

11.1 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


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. het bereiken van een specifieke workflowstatus

2. 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.

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.

Figuur 9 - Taken in de werkvoorraad


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:


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


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. Campagne management

Voor het uitvoeren van campagnemanagement ondersteunt FORCE de strategieën

projectmarketing en procesmarketing.

12.1 2.5.1. Projectmarketing

Projectmarketing kent een aantal vaste opvolgende fasen (zie onderstaande figuur) en kent een

begin en een eind.

I dee A nalyse Campagneplan Selectie Uitvoeren Evaluatie


Figuur 14 - Fasen projectmarketing

Grofweg bestaat het project uit voorbereiding, uitvoering en evaluatie. In alle fasen

ondersteunt FORCE op het gebied van projectmanagement. FORCE voert bij het uitvoeren van

de campagne veel stappen geautomatiseerd uit (bijvoorbeeld het genereren van mailings,

emails, verdelen van outbound calls en bewaking van het proces). De FORCE workflow engine

en business rule engine verzorgen de aansturing en bewaking van dit proces. Tijdens het proces

voert het systeem funnel management uit door continu de doorlooptijden en de conversie te

monitoren. In de evaluatie fase levert het systeem operationele rapportage waarin onder

andere terug te vinden is hoe lang processen geduurd hebben en wat de conversie van de

campagne was.

12.2 2.5.2. Procesmarketing

Procesmarketing zorgt voor een fijnmazige benadering van de klant, met als ultiem doel 1-op-1

marketing waarbij elke klant op de voor hem meest effectieve manier benaderd wordt. Onder

procesmarketing verstaat Topicus het acteren op een klant-event op basis van het profiel van

de klant.

Figuur 15 - Procesmarketing

Waar projectmarketing een begindatum en einddatum kent, is procesmarketing juist een

continu doorlopend proces. De campagne loopt continu en de klant wordt pas benaderd bij

relevante gebeurtenissen (events).

Figuur 16 - Fasen procesmarketing

FORCE biedt ondersteuning voor het geautomatiseerd ontvangen en afhandelen van events en

het bepalen binnen welk profiel een klant past. Een event kan gerelateerd zijn aan

productlifecycle, klantlevensloop en klantgedrag. Voorbeelden van productlifecycle events zijn:

• het vrijkomen van een deposito;

Campagneplan Idee Analyse

Event Uitvoeren Event Uitvoeren

Event Uitvoeren

Bijstellen Evaluatie


• het aanvragen van hypotheekadvies;

• de renteherziening van een hypotheek;

• het betalen van de ena-laatste termijn van een consumptief krediet.

Voorbeelden van klantlevensloop events zijn:

• het behalen van een bepaalde leeftijd;

• samenwonen of trouwen (af te lijden uit het product event “openen en/of-rekening”);

• krijgen van een kind;

• verhuizen;

• starten van een onderneming.

Voorbeelden van klantgedragingen zijn:

• het kopen van een auto;

• spaargedrag;

• bestedingsgedrag.

Klantprofielen zijn bijvoorbeeld ingedeeld op basis van eigenschappen van de klant, zoals

“heeft kinderen”, “valt in een bepaalde leeftijdsgroep”, “heeft een bepaald opleidingsniveau”,

“heeft een eigen huis”. Maar profielen kunnen ook betrekking hebben op klantsegmentering

(basis, advies, topadvies), rating of kredietrisico. Bij het vaststellen van de profielen geldt: hoe

fijnmaziger de profielen, hoe dichter de bank komt bij 1-op-1 marketing.

Wanneer een event zich voordoet bepaalt het profiel van de klant of de financiële instelling een

actie onderneemt, welke actie dit is en in welke vorm de dit gebeurt. Bijvoorbeeld: wanneer

een deposito vrijkomt, stuurt de instelling een notificatie naar alle klanten zonder

betalingsachterstand, met in de notificatie de huidige rentestanden van de verschillende

deposito’s van de instelling. Klanten beneden een bepaalde leeftijd krijgen een e-mail of krijgen

een boodschap als ze inloggen op Internetbankieren, klanten boven die leeftijd krijgen een

brief. De instelling belt adviesklanten na. Klanten die een betalingsachterstand hebben worden

vlak voor het vrijkomen van het deposito door de bijzonder beheer afdeling gebeld.

13 2.6. 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

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).

14 2.7. 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.

14.1 2.7.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

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.

14.2 2.7.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.

15 2.8. 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.

15.1 2.8.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

15.2 2.8.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.

15.3 2.8.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.:

• 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).

15.4 2.8.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”.

15.5 2.8.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

“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

15.6 2.8.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.

16 2.9. 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.

16.1 2.9.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.

16.2 2.9.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

één plek de audittrail component worden aangeroepen, waarna de component automatisch

alle gegevensmutaties voor dat bedrijfsproces registreert.


17 2.10. 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).

17.1 2.10.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.

17.2 2.10.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.

Dit gebeurt via de archiefbeheercomponent.


De archiefbeheercomponent draagt zorg voor:

• 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)

18 2.11. 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.

18.1 2.11.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.

18.2 2.11.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

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.

18.3 2.11.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.

18.4 2.11.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.

19 2.12. 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.

19.1 2.12.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:

• 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 contractanten productgegevens) voldoen

19.2 2.12.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

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.

19.3 2.12.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:

• 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)

19.4 2.12.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)


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.

19.5 2.12.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 “roll-back”

• het aanleveren van informatie voor rapportages en audits


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.

20 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


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.


21 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


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.

Topicus FORCE Framework · 2020. 2. 3. · Topicus – Singel 25, 7411 HW, Deventer – tel. 0570-...

Documents

Transcript of Topicus FORCE Framework · 2020. 2. 3. · Topicus – Singel 25, 7411 HW, Deventer – tel. 0570-...