Update 05/26

INHOUDSOPGAVE

1. PEP-screening: AI-ondersteunde controle op politieke prominente personen (PPP's)
2. Opgesplitste secties: Sancties en Politieke betrokkenheid
3. UBO-register document: automatische classificatie en tweerichtingssynchronisatie
4. AdminPulse-integratie: automatisch archiveren van inactieve klanten
5. Gestandaardiseerde placeholders in e-mailtemplates
6. Verbeteringen aan tabellen en leesbaarheid
7. Statusindicatoren identiteitskaart op de Relaties-pagina
8. Alfabetische dropdownmenu's
9. Opgeschoonde audit logs
10. Bugfixes
11. Uitbreiding van de Developer API

1. PEP-screening: AI-ondersteunde controle op politieke prominentie

We introduceren een nieuwe AI-ondersteunde controle die automatisch nagaat of een klant - of een nauw verbonden persoon - een politiek prominent persoon (PEP) is. PEP's dragen een verhoogd risicoprofiel en vereisen bijkomende waakzaamheid in het kader van uw antiwitwasverplichtingen.

Hoe werkt het?

• De AI-check loopt automatisch bij het aanmaken of bijwerken van een klant.
• De controle vertrekt van de naam, het bedrijf en het adres van de klant en geeft terug of de persoon als mogelijke PEP wordt gesignaleerd, samen met onderbouwende details.
• Alle bestaande klanten werden via een datamigratie retroactief gescand. De resultaten zijn dus meteen beschikbaar, zonder dat u zelf iets hoeft te doen.

Belangrijk: deze AI-controle is een aanvullende indicatie en geen sluitende bepaling van de PEP-status. Ze ondersteunt uw beoordeling, maar vervangt niet de bestaande bronnen (Rekenhof, Vlaamse Mandatendatabank) of uw eigen inschatting als AWW-verantwoordelijke. De eindbeoordeling blijft bij u.

2. Opgesplitste secties: Sancties en Politieke betrokkenheid

Om het overzicht te verbeteren, werd de vroegere sectie "Sancties en Mandaten" opgesplitst in twee afzonderlijke onderdelen, zowel in de linkernavigatie als op de overzichtsschermen:

• Sancties - nationale sancties, Europese sancties, Europees inreisverbod en VN-sancties.
• Politieke betrokkenheid - Rekenhof, Vlaamse Mandatendatabank, de nieuwe AI-check en Risico.

Daarnaast werd de lay-out van alle AI-overzichtsschermen (Adverse Media, Sancties, Politieke betrokkenheid) opgefrist voor een betere leesbaarheid: een betere uitlijning van rijen en selectievakjes, vernieuwde navigatie-iconen en links uitgelijnde tekst.

3. UBO-register document: automatische classificatie en tweerichtingssynchronisatie

Het uploaden en beheren van UBO-registerdocumenten verloopt voortaan een stuk eenvoudiger dankzij automatische classificatie en synchronisatie in twee richtingen.

Wat is er nieuw?

• Bij de bijlagen van een klantdossier werd een nieuwe documentcategorie "UBO-registerdocument" toegevoegd.
• In de editor voor vragenlijstdocumenten is er een nieuwe schakelaar "Voor UBO-registerdocument". Wanneer deze is ingeschakeld:
  • wordt een UBO-document dat via de vragenlijst wordt geüpload, automatisch opgeslagen onder de nieuwe sectie "UBO-registerdocument" in de bijlagen van de klant;
  • wordt omgekeerd een UBO-document dat rechtstreeks bij de bijlagen wordt geüpload, automatisch ingevuld bij de bijbehorende vraag in de vragenlijst en als voldaan gemarkeerd;
  • blijven beide locaties gesynchroniseerd bij het verwijderen of hernoemen van het document.
• Deze schakelaar is wederzijds uitsluitend met de bestaande schakelaar "Voor identiteitsbewijs natuurlijke persoon": slechts één van beide kan tegelijk actief zijn.

4. AdminPulse-integratie: automatisch archiveren van inactieve klanten

Voor kantoren die de AdminPulse-integratie gebruiken, is er een nieuwe optionele instelling die het klantenbestand consistent houdt tussen AdminPulse en AMLCare.

Wat is er nieuw?

• In de instellingen van de AdminPulse-integratie vindt u voortaan de instelling "Inactieve klanten archiveren".
• Wanneer deze is ingeschakeld, detecteert de synchronisatie klanten die in AdminPulse als inactief werden gemarkeerd - herkenbaar aan een endDate die vandaag of in het verleden ligt - en archiveert AMLCare de overeenkomstige klant automatisch.
• De matching gebeurt volgens de bestaande logica: eerst op KBO- of registratienummer, daarna op een exacte match van naam + e-mail.
• Belangrijke beveiliging: inactieve AdminPulse-relaties worden nooit als nieuwe klant in AMLCare aangemaakt. Deze functie archiveert uitsluitend klanten die al in AMLCare bestaan.
• Wanneer de instelling is uitgeschakeld (de standaardinstelling), verandert er niets aan uw bestaande werkwijze.

5. Gestandaardiseerde placeholders in e-mailtemplates

E-mailtemplates gebruiken voortaan een duidelijke, consistente set placeholders die correct werken voor zowel bedrijfsklanten als natuurlijke personen. Dit elimineert verwarrende NA-waarden en dubbelzinnige benamingen.

Wat is er nieuw?

• Nieuwe placeholders:
  • {{customerName}} verwijst altijd naar de klantnaam (bedrijfsnaam voor bedrijven, volledige naam voor natuurlijke personen);
  • {{contactFullName}} verwijst altijd naar de aangesproken persoon (contactpersoon voor bedrijven, de klant zelf voor natuurlijke personen);
  • {{contactFirstName}} en {{contactLastName}} : voor- en achternaam van de contactpersoon.
• Voor e-signingtemplates(Sign Invite, Reminder Sign Invite, Signs Completed):
  • een nieuwe placeholder {{signerFullName}} verwijst expliciet naar de ondertekenaar van het document. Hiermee verdwijnt de vroegere dubbelzinnigheid waarbij {{customerFullName}} afhankelijk van de context zowel voor de klant als voor de ondertekenaar werd gebruikt;
  • de gestandaardiseerde placeholders {{customerName}}, {{contactFullName}}, {{contactFirstName}} en {{contactLastName}} zijn nu ook beschikbaar in ondertekentemplates.
• Automatische migratie: alle bestaande templates in alle backoffices werden automatisch bijgewerkt. {{customerFullName}} werd vervangen door {{customerName}} (of {{signerFullName}} in ondertekentemplates) en {{contactPerson}} door {{contactFullName}}. U hoeft zelf niets aan te passen.

6. Verbeteringen aan tabellen en leesbaarheid

Tabellen doorheen AMLCare werden aangepast om visuele overlap te vermijden en de bruikbaarheid op verschillende schermformaten te verbeteren.

Wat is er verbeterd?

• Kolomkoppen en inhoud overlappen niet langer bij smalle browservensters.
• Er geldt voortaan een minimale tussenruimte van 12px tussen kolommen.
• De kolommen Naam en E-mail hebben een minimumbreedte van 100px; Risico-kolommen zijn vast ingesteld op 110px zodat de volledige labels in alle talen leesbaar blijven; datum kolommen hebben een minimumbreedte van 70px om een volledige datum (DD/MM/JJJJ) op één lijn te tonen.
• Kolomkoppen en hun inhoud zijn nu correct uitgelijnd.

7. Statusindicatoren identiteitskaart op de Relaties-pagina

U ziet voortaan in één oogopslag welke verbonden personen van een bedrijf een probleem hebben met hun identiteitskaart - rechtstreeks vanaf de Relaties-pagina, zonder dat u elke persoon afzonderlijk hoeft te openen.

Wat is er nieuw?

De volgende statusiconen verschijnen naast elke persoon op de Relaties-pagina:

• ? Oranje kalender - de identiteitskaart vervalt binnen 2 weken.
• ? Rode kalender - de identiteitskaart is reeds vervallen.
• ? Rood uitroepteken - de vervaldatum van de identiteitskaart ontbreekt, of er is geen identiteitskaart geüpload.

Wanneer u met de muis over een icoon zweeft, verschijnt een tooltip met dezelfde uitleg als op de pagina Overzicht klanten. De kleuren van de iconen werden aangepast om te voldoen aan de toegankelijkheidsnormen.

8. Alfabetische dropdownmenu's

Dropdownmenu's doorheen AMLCare tonen hun opties voortaan in alfabetische volgorde, zodat u sneller de gewenste waarde terugvindt.

Waar geldt dit?

• Klant aanmaken → veld Verantwoordelijke
• Nieuwe taak toevoegen → velden Categorie en Toewijzen aan collega
• Zoekvelden voor labels (zowel standaard als geavanceerd labelbeheer)
• Filterdropdowns op de pagina's Overzicht klanten, Overzicht personen, Overzicht bedrijven, Adverse Media, Sancties en Mandaten, en E-signatures.

(Uitzondering: de dropdowns in de audit log behouden hun logische sectievolgorde.)

9. Opgeschoonde audit logs

Audit logs registreren niet langer elke wijziging in het invullingspercentage van een vragenlijst. Voorheen genereerde elke incrementele voortgang (bijvoorbeeld van 40% naar 45%) een afzonderlijke logregel, wat de log vervuilde met ruis van weinig waarde.

Wat is er gewijzigd?

• Wijzigingen in percentages voor zowel interne als externe vragenlijsten worden niet langer in de audit log geschreven.
• Registraties van voltooide taken (bijvoorbeeld "De volgende taak werd als voltooid gemarkeerd: XXX") worden nog steeds gelogd zoals voorheen.

10. Bugfixes

Foutmelding "Duplicaat KBO-nummer" bij het bewerken van een klant Voorheen kon het bewerken van klantgegevens (zoals het adres) mislukken met een foutmelding "Duplicaat KBO-nummer", zelfs wanneer er geen werkelijk duplicaat in het systeem bestond. Dit werd veroorzaakt door een matchingprobleem in de backend dat het eigen KBO-nummer van de klant onterecht als conflict markeerde. Dit is opgelost; klantgegevens bewerken slaagt nu correct.

Omzeiling van labelgebaseerde toegangscontrole bij klantzoekopdrachten Interne gebruikers met beperkte labeltoegang (bijvoorbeeld enkel klanten met het label van hun eigen kantoor) konden via de zoekfunctie elke klant in het systeem terugvinden, ongeacht de labelbeperkingen. Het openen van een klant waartoe zij geen toegang hadden, logde hen geforceerd uit. Dit is opgelost: zoekresultaten respecteren voortaan de labelgebaseerde toegangscontrole en gebruikers zien enkel klanten die overeenkomen met hun toegewezen labels.

Velden contactpersoon niet vooraf ingevuld in vragenlijsten Bij het aanmaken van een nieuwe bedrijfsklant met gegevens van een contactpersoon (naam, e-mail, telefoonnummer) en het vervolgens toevoegen van een vragenlijst, werden de velden van de contactpersoon in de sectie "betreffende" van de vragenlijst niet automatisch ingevuld vanuit het klantdossier. Deze velden worden nu correct vooraf ingevuld.

Automatische onderteken herinneringen werden niet betrouwbaar verstuurd Nadat een document gedeeltelijk was ondertekend (minstens één ondertekenaar had getekend, maar anderen nog niet), werden automatische onderteken herinneringen ofwel niet verstuurd, ofwel slechts eenmaal in plaats van volgens het ingestelde herinneringsschema. Dit is opgelost - herinneringen worden nu volgens de ingestelde instellingen naar alle openstaande ondertekenaars verstuurd.

11. Uitbreiding van de Developer API

Deze release bevat een belangrijke uitbreiding van de AMLCare Developer API, met verschillende nieuwe endpoints en uitbreidingen van bestaande endpoints. Deze wijzigingen zijn relevant voor teams die integraties of automatiseringen bovenop AMLCare bouwen.

Nieuwe endpoints

• Archive Customers archiveert een lijst van klant-ID's in bulk. Handig voor programmatische opschoning of integratiegestuurd lifecyclebeheer.
• Archive CAPs archiveert een lijst van CAP-ID's (Customer Acceptance Procedure) in bulk.
• GET /settings/labels haalt alle labels op kantoorniveau op. Indien geavanceerde labels zijn ingeschakeld, worden deze overeenkomstig teruggegeven.
• POST /settings/labels maakt nieuwe labels aan, met validatie om duplicaten te vermijden. Voor geavanceerde labels op kantoorniveau worden enkel geauthenticeerde labels aanvaard.
• Create Tasks laat toe taken voor een klant aan te maken via de API — een voorwaarde om de CAP- en multi-CAP-functies via integraties te laten werken.

Uitbreidingen aan bestaande endpoints

• Het attachments-endpoint ondersteunt voortaan het uploaden van identiteitskaarten door het opgeven van het bijlagetype.

• De endpoints Customer POST/PUT aanvaarden voortaan metadata van de identiteitskaart. U kunt vervaldatum, geboortedatum en geboorteplaats rechtstreeks instellen bij het aanmaken of bijwerken van een klant, zonder aparte oproep.

• Veld country toegevoegd aan de klant-endpoints. Een nieuw optioneel veld country is beschikbaar bij het aanmaken en bijwerken van klanten. Wordt het weggelaten, dan wordt België (BE) verondersteld voor achterwaartse compatibiliteit. Voor niet-Belgische registratie- of ondernemingsnummers is het veld verplicht, zodat de juiste validatieregels worden toegepast.

• De Swagger-documentatie werd bijgewerkt met volledige responseschema's voor het endpoint GET /customers.

• Uitgebreide API-testdekking werd toegevoegd over alle nieuwe en bijgewerkte endpoints.