Deze documentatie wordt actief uitgebreid — kom regelmatig terug.

CTN Member Onboarding Workflow

Vetting, Verification, and Credential Issuance Process Last Updated: 2025-11-18

Overview

This document describes the complete onboarding process for new participants joining the CTN Association Register. The process ensures that all participants are properly vetted, verified, and issued appropriate credentials before gaining access to the network.

Within the container transport ecosystem, proper vetting ensures that all parties who are approved participants of the CTN association can be trusted to:

Meet regulatory compliance requirements
Maintain secure data sharing practices
Participate effectively in CTN data sharing use cases

Onboarding Process Summary

graph LR
    A[Application] --> B[Vetting]
    B --> C[Verification]
    C --> D[Approval]
    D --> E[Credential Issuance]
    E --> F[Activation]
    F --> G[Ongoing Monitoring]

Phase 1: Business Vetting

1.1 Legal and Regulatory Verification

Company Registration: Confirm legal entity status and business registration
Business Licenses: Verify required permits and licenses for their industry
Regulatory Compliance: Check adherence to local, national, and international regulations
Ownership Structure: Review ultimate beneficial owners (UBOs) and corporate structure
Sanctions Screening: Screen against sanctions and restricted party lists

1.2 Compliance and Risk Screening

Anti-Money Laundering (AML): Perform comprehensive AML checks
Politically Exposed Persons (PEP): Check for PEP status among owners/management
Adverse Media: Conduct reputational screening for negative coverage
Litigation History: Review any history of legal disputes or proceedings

1.3 Capability and Capacity Evaluation

Operational Capacity: Assess facilities, equipment, and operational capability
Certifications: Review relevant certifications (ISO standards, industry accreditations)
Quality Control: Evaluate quality management processes and safety records
Technology Integration: Assess IT capabilities and readiness

1.4 Past Performance and References

Customer References: Gather testimonials from existing or past clients
Contract History: Review performance on previous contracts or projects
Dispute Resolution: Investigate history of contract disputes or performance issues
Industry Reputation: Assess standing within the logistics/transport industry

1.5 Contractual and Ethical Standards

Terms Acceptance: Confirm acceptance of company terms and conditions
Ethical Standards: Review adherence to ethical sourcing and corporate responsibility
Sustainability Practices: Evaluate environmental and sustainability commitments
Data Protection: Assess data protection and cybersecurity practices

1.6 Financial Assessment

Note: Financial assessment is not the responsibility of the CTN association. Each participant should conduct their own financial due diligence.

Credit reporting and financial statements
Payment history and outstanding debts
Financial stability and liquidity
Insurance coverage for transport/logistics operations

Phase 2: Initial Application

2.1 Application Submission

Prospective Participant Applies
- Submits application through member portal
- Provides basic company information
Document Collection
- Chamber of Commerce Statement
- Identification documents (eHerkenning for NL)

2.2 Document Requirements

Required Documents

Legal Entity Documents
- Chamber of Commerce statement (< 3 months old)
- UBO statement
Identification Documents
- Valid ID for authorized signatories
- Proof of authorization
- eHerkenning in NL
Business Documents
- VAT registration
- Insurance certificates
- Compliance certifications

Document Validation Criteria

Authenticity: Documents must be original or certified copies
Currency: Documents must be recent (typically < 3 months)
Completeness: All required fields must be present
Consistency: Information must match across documents

Phase 3: Verification

3.1 Automated Document Processing

Azure AI Document Intelligence extracts data
Validates document authenticity when eHerkenning is used
Cross-references with external registries

3.2 External Registry Verification

Chamber of Commerce / national business registers

Verification using the national register number as parameter (CoC number).
Multi-country sources (see Identifier Enrichment Architecture): KvK (NL), KBO (BE), Handelsregister (DE — live handelsregister.de or the OffeneRegister.de open-data bulk), recherche-entreprises (FR → SIREN + SIRET per establishment), Zefix / LINDAS (CH → UID, the LINDAS SPARQL endpoint needs no account).

LEI (Legal Entity Identifier)

Enrichment via GLEIF using the national register number as parameter; for name-only discovery use the GLEIF fuzzy-completion endpoint (the legalName filter requires a near-exact match).

EUID (European Unique Identifier)

Standardized identifier format for legal entities across the EU. Canonical definition: see the Glossary and the dotted form used throughout the architecture.
Format: {country}.{register}.{number} — e.g. NL.KVK.12345678, BE.KBO.0123456789, DEK1101R.HRB116737 (DE includes the Amtsgericht/court code, derivable from OffeneRegister). (A compact BRIS variant NLHR12345678 also exists; the architecture uses the dotted form.)

EORI (Economic Operators Registration and Identification)

Used for customs operations and trade with non-EU countries
Required for importing/exporting goods outside the EU
Format: Country code + unique number (e.g., NL123456789000)
Managed by national customs authorities

VIES (VAT Information Exchange System)

Validates VAT numbers for cross-border EU transactions
VIES VAT Validation API: https://ec.europa.eu/taxation_customs/vies/
Input: Country code + VAT number
Output: Validation status, company name, address

Note: VAT number can be obtained from KvK API and then validated via VIES API.

3.3 CTN-Specific Technical Vetting

Technical Readiness

Endpoint Registration: Verify and register URI(s) of system endpoint(s).
Association Participation: Register the association of which the entity is a participant.
Connector Implementation: Assess API capabilities.

Security Assessment

JWKS Endpoint: Confirm proper JWKS endpoint implementation
Token Validation: Test VAD validation capabilities
Encryption Standards: Verify compliance with security standards

Integration Testing

Connectivity Testing: Perform end-to-end connectivity tests
Data Format Compliance: Verify compliance with CTN data formats
Event Handling: Test event notifications and updates
Error Handling: Assess recovery mechanisms

3.4 Verification Methods

Automated Verification

Document AI Processing
- OCR extraction of text
- Field recognition and validation
- Signature detection
- Tamper detection
API Verification
- Chamber of Commerce API
- GLEIF LEI verification
- VIES validation service

Manual Verification

Document Review
- Visual inspection of documents
- Cross-reference with external sources
- Flag suspicious documents
- Request additional information if needed
Business Vetting
- Industry sector verification
- Reputation check
- Compliance history review
- Reference checks

3.5 Verification model

Each onboarding check is recorded as a Verification with a type, a category, and a status. Verifications are authoritative in the ASR (never mirrored into Keycloak — see ADR-00003).

Status lifecycle: Pending → Approved / Rejected; an Approved verification can later be Revoked.

Categories:

Automatic — resolved by a system/API call (e.g. KvK, KBO, VAT, LEI).
ByAdmin — requires association/admin approval (e.g. onboarding approval, business-register extract review).
ByOrganization — a step the participant performs themselves (e.g. eHerkenning, conditions-of-use acceptance).

Verification types: OnboardingApproval, KvkCheck, KboCheck, VatCheck, LeiCheck, DnsVerification, EmailVerification, EHerkenning, BusinessRegisterExtract, ConditionsOfUseAcceptance. The set is open for extension; a participant’s trust level is derived from which verifications are Approved.

3.6 eHerkenning step-up verification

eHerkenning is used as a step-up verification, not a login. The user is already authenticated via their normal session; the eHerkenning assertion proves they represent the organisation by matching the KvK number.

Flow: the portal issues an OIDC challenge with kc_idp_hint=eh and prompt=login; on callback the kvk claim is cross-checked (trimmed, case-insensitive) against the participant’s stored KvK. On match, the EHerkenning verification is set to Approved with compact evidence {"kvk": "...", "jti": "..."} (the jti links to the Keycloak admin event for audit).

Guardrails (proven in the Poort8 prototype):

eHerkenning is hidden on the Keycloak login page and only reachable via kc_idp_hint=eh, so it cannot be bypassed with username/password — otherwise a verification could be marked “proven via eH” without eH involvement.
The callback never mutates the main session (it is an assertion, not account linking).
Verification context is carried in the OIDC state, not the session cookie, so the flow survives third-party-cookie blocking (e.g. private-browsing).
Any broker-created Keycloak user is deleted after the callback to prevent orphan accounts.

Phase 4: Approval

4.1 Association Administrator Review

Manual review of verification results
Assessment of application completeness
Decision on membership approval

4.2 Identity Assurance Level Assignment

Based on the verification methods used, participants are assigned an Identity Assurance Level (IAL):

IAL	Verification Method	Trust Level
IAL1	Company name + CoC number only	Basic
IAL1	DNS verification (DNS-token in TXT record)	Basic
IAL2	Recent CoC statement submitted	Substantial
IAL3	eHerkenning registration	High

4.3 Risk Classification

Based on vetting results, assign risk classification:

Low Risk: Full access with minimal monitoring
Medium Risk: Standard access with regular monitoring
High Risk: Limited access with enhanced monitoring
Conditional: Temporary access pending additional verification

4.4 Decision Framework

Full Approval

All vetting criteria met satisfactorily
Full participation: VAD issued; may register endpoints and consume/provide data
Standard monitoring and review schedule

Conditional Approval

Most criteria met with minor deficiencies
Limited or monitored access initially
Specific conditions for full approval status

Rejection

Critical vetting criteria not met
No VAD issued; cannot participate in the network
Option for re-evaluation after remediation

Phase 5: Credential Issuance

5.1 VAD Token Generation

JWT-based verifiable credential including:

Legal entity information
LEI, CoC number, VIES
Membership tier
Valid from/until dates
Access scopes
Identity Assurance Level

5.2 Token Claims Structure

{
  "iss": "https://association.ctn.network",
  "sub": "client_id",
  "aud": "https://ctn.network",
  "iat": 1704063600,
  "exp": 1704150000,
  "nbf": 1704063600,
  "jti": "unique-token-id",
  "https://schemas.ctn.network/claims/legal_entity/name": "Company Legal Name",
  "https://schemas.ctn.network/claims/legal_entity/lei": "LEI123456789012345678",
  "https://schemas.ctn.network/claims/legal_entity/kvk": "12345678",
  "https://schemas.ctn.network/claims/participation/status": "active",
  "https://schemas.ctn.network/claims/identity_assurance_level": "ial2",
  "https://schemas.ctn.network/claims/terms/version": "v3.2.0"
}

5.3 Secure Delivery

Security Measures
- Multi-factor authentication required
- Secure download link via email
- Time-limited access to credentials (24 hours)
- Confirmation of receipt required
Storage Recommendations
- Secure key vault usage
- Encrypted storage
- Access control
- Regular rotation

Phase 6: Activation

6.1 Member Portal Access

Credentials activated
Initial login and profile setup
OAuth client registration
API key generation

6.2 Integration Support

Documentation provided
Technical support available
Sandbox environment access
Testing period

6.3 Internal System Registration

Once vetting is complete and approved, the following information is registered:

Basic Company Information

Legal name and trading names
Registration numbers (KvK, LEI, etc.)
Business address and contact information
Key contact persons and roles

CTN-Specific Information

Domain: Primary domain for identification
Endpoints: All registered API endpoints
Association Details: Which Association they belong to
Capabilities: Specific services they can provide or consume

Operational Details

Service capabilities and capacity
Geographic coverage
Supported transport modes
Quality certifications and standards

Phase 7: Ongoing Monitoring

7.1 Regular Review Schedule

Annual Review: Comprehensive re-vetting for all participants
Quarterly Monitoring: Check against Chamber of Commerce API
Event-Driven Review: Triggered by significant changes or incidents

7.2 Continuous Monitoring

Sanctions Lists: Ongoing screening against updated sanctions lists
Media Monitoring: Continuous adverse media screening
Performance Tracking: Ongoing assessment of contract performance

7.3 CTN-Specific Monitoring

Endpoint Health: Regular monitoring of endpoint availability
Security Updates: Monitoring for security patches and certificate renewals
Compliance Drift: Regular assessment of continued compliance
Integration Performance: Monitoring of integration performance metrics

Workflow Automation

Event-Driven Architecture

Application Submitted → Event published
Documents Uploaded → AI processing triggered
Verification Complete → Approval workflow triggered
Application Approved → VAD generation triggered
VAD Issued → Notification sent

Azure Services Used

Kubernetes (AKS, via Helm + ArgoCD): hosts the Quarkus ASR services and background jobs
Document Intelligence: AI document processing (e.g. Azure Document Intelligence / AWS Textract)
Key Vault: Secret management and HSM-backed signing keys

Timeline and SLAs

Standard Processing

Phase	Duration
Application Review	1-2 business days
Document Verification	2-3 business days
Approval Decision	1 business day
Total	4-6 business days

Expedited Processing

Available for premium/enterprise tiers
Total: 1-2 business days
Additional fee may apply

Quality Controls

Data Quality

Validation rules for all fields
Cross-reference checks
Duplicate detection
Data enrichment from external sources

Process Quality

SLA monitoring (e.g., verification within 2 business days)
Quality assurance reviews
Customer feedback collection
Continuous process improvement

Documentation Requirements

Complete vetting file for each approved participant
Regular update of participant information
Audit trail of all vetting decisions
Evidence supporting approval/rejection decisions

Compliance and Audit

Data minimization
Consent management
Right to access/correction/deletion
Data retention policies
Privacy by design

Audit Trail

All actions logged with user, timestamp, and changes
Document access tracking
Approval decisions recorded
Token issuance logged

Error Handling

Common Issues

Incomplete Documents
- Automated notification to applicant
- Clear indication of missing items
- Resubmission workflow
Verification Failures
- Manual review triggered
- Applicant contact for clarification
- Alternative verification methods
External API Failures
- Retry logic with exponential backoff
- Fallback to manual verification
- Monitoring and alerting

Support and Communication

Communication Channels

Email notifications at each stage
SMS alerts (optional)
Portal notifications
Support ticket system

Support Availability

Basic: Business hours
Premium: Extended hours
Enterprise: 24/7

Integration with CTN

Association Register Role

The Association Register serves as the trust anchor for the CTN ecosystem:

Participant Directory
- Authoritative source of participant information
- LEI/CoC/EORI to Client ID mapping
- Membership status and tier
VAD Token Provider
- Issues verifiable membership credentials
- Validates participant identity
- Provides trust foundation for local authorisation at data providers
Access Control
- Determines participant access levels
- Enforces tier-based restrictions
- Manages API quotas

Data-Provider Integration (2026)

Data providers validate the VAD against the ASR’s JWKS endpoint before releasing data.
VAD claims indicate participation tier and verification status.
The provider’s own local policy decides the resulting data shape.

References

Association Register Architecture

This document provides implementation guidance for CTN participants and should be adapted to specific organizational requirements and risk tolerance.

In samenwerking met