KYB-testen is het werk om ervoor te zorgen dat een bedrijfsverificatiestroom correct werkt voordat die een echte aanvrager ontmoet. KYB staat voor Know Your Business, en de naam wijst op het verschil dat ertoe doet: het onderwerp dat wordt geverifieerd is een organisatie, geen persoon, en een organisatie heeft lagen — eigenaren, zeggenschaphebbers, registraties, documenten — waarmee een persoonlijke identiteitscontrole nooit te maken krijgt.
Dit artikel zet uiteen wat een KYB-stroom werkelijk verifieert, waarom bedrijfsverificatie moeilijker is dan persoonlijke verificatie, hoe afwijzing en beoordeling zich zouden moeten gedragen, en hoe je het geheel test zonder de controles te verzwakken die je aan het testen bent.
Wat verifieert een KYB-stroom werkelijk?
Hij verifieert dat de organisatie echt is, dat ze is wat ze beweert te zijn, en dat de mensen erachter zijn wie ze zeggen te zijn. Een persoonlijke identiteitscontrole beantwoordt “is deze persoon wie hij beweert”; een bedrijfscontrole beantwoordt dezelfde vraag over een entiteit en voegt dan een tweede vraag toe over de mensen die haar beheersen.
Een typische stroom verzamelt daarom verschillende soorten bewijs, en de specifieke vereisten hangen af van het rechtsgebied en van de toezichthouder waaraan het onboardende bedrijf verantwoording verschuldigd is. In grote lijnen:
- Bestaan — bewijs dat de entiteit is geregistreerd, afkomstig uit het register van het land van oprichting.
- Identificatie — het registratienummer en elke fiscale of btw-identificatie die de entiteit heeft.
- Locatie — bewijs van het geregistreerde adres, en soms ook van een operationeel adres.
- Eigendom en zeggenschap — de personen die de entiteit uiteindelijk bezitten of beheersen.
- Activiteit — wat het bedrijf werkelijk doet, en elke vergunning of permit die die activiteit vereist.
- Vertegenwoordiging — bevestiging dat de persoon die indient bevoegd is om namens de entiteit te handelen.
Geen van deze is een formaliteit, en geen van deze kan uit een andere worden afgeleid. Een geregistreerd bedrijf kan ondoorzichtig eigendom hebben, een vergunning kan worden gehouden maar verlopen zijn, en de persoon die het formulier invult is vaak geen bestuurder.
Waarom is het verifiëren van een bedrijf moeilijker dan het verifiëren van een persoon?
Drie structurele redenen, die allemaal als defecten in het testen opduiken.
De eerste is gelaagdheid. Een persoon is één subject met één identiteit. Een bedrijf kan eigendom zijn van een ander bedrijf, dat eigendom is van een trust, die in een derde land wordt beheerd. De stroom moet die keten ver genoeg volgen om de mensen aan het einde ervan te identificeren, en “ver genoeg” is een oordeel in plaats van een vast aantal stappen.
De tweede is dat het bewijs verspreid is. Persoonlijke identiteitsdocumenten komen van één autoriteit in één land. Bedrijfsbewijs komt van een register hier, een belastingdienst daar, en een bank elders, in meerdere talen, met verschillende geldigheidsperioden en verschillende mate van openbare toegankelijkheid.
De derde is dat de verificatie geen enkele gebeurtenis is. Eigendom verandert, adressen veranderen, vergunningen verlopen, entiteiten worden hernoemd of geherstructureerd. Een bedrijf dat het ene jaar de verificatie doorstond, kan het volgende jaar een wezenlijk ander beeld tonen.
Wat moet de aanvrager indienen?
Dat hangt af van het rechtsgebied en van het risicoprofiel dat de verifiërende instelling toepast, maar een representatieve set vereisten ziet er zo uit.
| Vereiste | Wat ze vaststelt | Notities voor testers |
|---|---|---|
| Oprichtingsakte of gelijkwaardig | De entiteit bestaat en haar naam en nummer zijn zoals beweerd | Vaak gecombineerd met een recent uittreksel uit het register |
| Bewijs van fiscale of btw-registratie | De fiscale identiteit van de entiteit | Bestaat misschien niet voor elk legitiem bedrijf |
| Bewijs van geregistreerd adres | Waar de entiteit officieel is gevestigd | Een energierekening of registeruittreksel, afhankelijk van het land |
| Informatie over eigendom of zeggenschap | Wie de entiteit uiteindelijk bezit of beheerst | Het moeilijkste deel om te modelleren en te testen |
| Identiteitsdocumenten van zeggenschaphebbers | Dat de personen echt zijn | Lokt een aparte persoonlijke controle uit |
| Vergunning of permit | Dat een gereguleerde activiteit is toegestaan | Ontbreekt voor de meeste ongereguleerde bedrijven |
De cruciale technische observatie staat in de laatste kolom van de middelste rijen: verschillende van deze items zijn optioneel op een manier die legitiem is in plaats van onvolledig. Een bedrijf zonder btw-registratie is geen gebrekkige aanvrager, en een stroom die afwezigheid als falen behandelt, zal een groot deel van de echte markt afwijzen.
Hoe zouden afwijzing en beoordeling zich moeten gedragen?
Als gewone, verwachte toestanden in plaats van als terminale fouten. Een verificatiestroom die alleen in goedkeuring of in een doodlopende weg kan eindigen, is een stroom waarvoor de mensen die hem beheren een omweg zullen zoeken, en om een controle heen werken is hoe controle verloren gaat.
Ontwerp de uitkomsten apart. Een afwijzing op gedocumenteerde gronden — bijvoorbeeld een document dat niet overeenkomt met het register — is herbeoordeelbaar en aanvechtbaar. Een verzoek om meer informatie is een hervatbare toestand die alles wat al is ingediend bewaart. Een handmatige beoordelingswachtrij is een legitieme uitkomst, geen mislukking van automatisering. En elke afwijzing moet een reden dragen die specifiek genoeg is om actiegericht te zijn, want “verificatie mislukt” geeft de aanvrager niets om te corrigeren en het supportteam niets om uit te leggen.
Twee eigenschappen maken deze toestanden van theorie tot een werkbare stroom. Afwijzingsredenen moeten een gecontroleerd vocabulaire zijn, zodat ze consistent kunnen worden geteld, gerouteerd en beantwoord. En een afgewezen aanvraag moet hervatbaar zijn: de aanvrager corrigeert één document, niet de hele inzending.
Wat niet mag gebeuren, is een testshortcut die de controles uitschakelt. De sanctie-, eigendoms- of documentcontroles uitzetten om een test te laten slagen, levert een systeem op waarvan de fouten onzichtbaar zijn tot ze duur zijn.
Voor ontwikkelaars: toestanden, bewijs en bewaring
Modelleer de stroom als een expliciete toestandsmachine — niet gestart, ingediend, in beoordeling, wachtend op informatie, goedgekeurd, afgewezen — met vastgelegde overgangen, tijdstempels en de actor die voor elk verantwoordelijk is. Een statusveld dat een vrij-tekst-string is, gaat binnen een maand schuiven, en de drift blijft onzichtbaar tot iemand erover probeert te rapporteren.
Bewijs heeft zijn eigen model nodig. Elk ingediend document moet een type, een uitgever of land, de datum van uitgifte en, waar van toepassing, een vervaldatum dragen, want een vergunning die is verlopen is geen bewijs ook al staat het bestand er nog. Scheid de metadata van het document van het bestand zelf, zodat bewaarregels op de metadata kunnen werken zonder de inhoud aan te raken.
Uiteindelijke begunstigden zijn het deel dat teams onderschatten. Modelleer het als een graaf — entiteiten en personen als knopen, eigendom en zeggenschap als randen — ook al toont de interface ooit maar twee niveaus. Het afvlakken tot een paar naamvelden maakt de gegevens onbruikbaar zodra een eigendomsstructuur opnieuw moet worden gecontroleerd.
Bewaring en isolatie zijn de andere niet-onderhandelbare punten. Verificatiebewijs hoort bij het meest gevoelige materiaal dat een bedrijf bezit, dus houd testomgevingen vrij van echte documenten en echte aanvragers, en houd productiegegevens volledig buiten testdatabases. De synthetische entiteiten die de generator voor bedrijfsgegevens produceert, zijn de juiste invoer om deze stroom te repeteren: ze beschrijven geen echt bedrijf, en het artikel over de grenzen van synthetische bedrijfsgegevens legt uit waarom dat ertoe doet wanneer een screenshot of een export zijn omgeving verlaat. De bredere machinerie van synthetische bedrijfsrecords wordt behandeld in testbedrijfsgegevens.
Volgende stappen
Schrijf elke toestand op waarin je verificatiestroom zich kan bevinden, en controleer dan of elke toestand in een testomgeving bereikbaar is en of elke een actiegerichte melding voor de aanvrager draagt. Elke toestand die in het testen niet kan worden betreden, is een toestand die voor het eerst in productie zal worden betreden. Repeteer dan de stroom end-to-end met een gegenereerd bedrijf uit de generator voor bedrijfsgegevens en bevestig dat geen enkele stap vereist dat je een controle uitschakelt om erdoor te komen.