This repository contains source code and design documents for the MOSIP Registration Processor, a server-side module used to manage the ID lifecycle. The module exposes API endpoints and follows the SEDA architecture, where data flows through multiple stages.

The front end UI application called Registration Client is available in a separate repository here

The registration packet structure is available here : Packet structure

Vertx is the framework used to run the stages, and each stage operates as a Vertx component.

Registration processor stages are connected with eventbus. MOSIP supports two types of eventbus:

• Vertx Eventbus
• Kafka (default) : Provides persistence across restarts (more robust), throttling capacity and better debugging.

Kafka offers certain advantages over Vertx eventbus hence it is recommended as the default eventbus mechanism. All events between stages pass through Kafka queues. There is a separate Kafka topic for each stage.

One of the power features is to enable throttling in the pipeline. See Throttling

Hazelcast is used as a distributed cache for packet manager.

• Multi-stage processing pipeline (SEDA architecture) for scalable and asynchronous packet processing.

• Packet validation and quality checks, including biometric quality assessment using external SDKs.

• Biometric deduplication through integration with ABIS using middleware and messaging queues.

• Manual adjudication support via queue-based integration with external adjudication systems.

• Secure packet handling using Key Manager for encryption/decryption and Datashare for controlled data access.

• Automated notifications via email/SMS using Notification Service.

• High reliability with Kafka-based event bus, retries and configurable stage flows.

• End-to-end ID lifecycle management supporting multiple registration flows such as :(New, Update, Correction, Child, Lost, Activate/Deactivate, Reprint, CRVS New, CRVS Death).

  • New
  • Update
  • Child
  • Correction
  • Lost
  • Activate/deactivate
  • Reprint
  • CRVS New
  • CRVS Death
  • The stage sequence against each flow refer here

The Registration Processor organizes its processing flow into distinct stage groups. These stage groups are outlined below.

• Group 1
  • Packet receiver : Receives registration packets uploaded from the Registration Client and stores them securely for processing.
• Group 2
  • Securezone notification : Sends notifications to the SecureZone system following the initial sanity checks and assists in controlling the traffic flow to the next processing stages.
  • Quality classifier : Checks biometric quality (fingerprint/iris/face) using a biometric SDK to ensure data meets required quality standards.
  • Message sender : Responsible for sending notifications as the packet progresses through the stages.
• Group 3
  • ABIS handler : Responsible for preparing the request data to be sent to ABIS for deduplication.
  • ABIS middleware : Responsible for communicating with ABIS asynchronously.
  • Bio dedupe : Performs biometric deduplication with the help of ABIS to ensure the uniqueness of biometric data.
  • Manual adjudication : Asynchronously sends cases to the external manual adjudication system and receives decisions for applications requiring human review due to biometric duplicate issues.
• Group 4
  • Biometric authentication : Authenticates applicant, operator, introducer, or supervisor using biometric data via IDA Authentication Service.
  • Demo dedupe : Performs demographic deduplication to detect duplicate records using demographic matching rules.
• Group 5
  • CMD validator : Validates center, machine, device (CMD) information captured in the registration packet.
  • Operator validator : Validates the operator’s identity and authorization for performing the enrollment.
  • Supervisor validator : Validates the supervisor’s identity and authentication for performing approval.
  • Introducer validator : Validates introducer details for child enrollment.
  • Packet validator : Performs overall validation, including schema checks and verification of supervisor approval.
• Group 6
  • Packet uploader : Uploads sanitized registration packets for processing in MOSIP.
  • Packet classifier : Classifies packets into categories, such as by age or exceptional biometrics, to ensure proper handling in subsequent stages.
  • Verification : Asynchronously sends cases to the external manual verification system and receives decisions for applications requiring human review of documents in cases such as INFANT flows.
• Group 7 – Final Processing
  • UIN generator : Creates or updates a UIN draft using the applicant’s biometric and demographic data.
  • Biometric extraction : Performs biometric extraction to extract biometric templates from raw biometric data for storage and matching.
  • Finalization : Updates the processing status and finalizes the UIN draft in IDREPO as a UIN entry.
  • Credential requestor : Responsible for generating credentials for different partners, formerly known as the Print Service.

The control and data flow in the stages is controlled by Workflow engine

Supporting services:

• Registration status service: Responsible for syncing the registration packets from field.
• Notification service : Responsible for sending email/SMS notifications as the packet progresses through the stages.
• Transaction Service : Responsible for proving the transaction status of registration packets.

Before starting the local setup, execute the required SQL scripts to initialize the database.

All database SQL scripts are available in the db scripts directory.

The project can be set up in two ways:

1. Local Setup (for Development or Contribution)
2. Local Setup with Docker (Easy Setup for Demos)

Before you begin, ensure you have the following installed:

• JDK: 21.0.3
• Maven: 3.9.6
• Docker: Latest stable version

• Add kernel-auth-adapter.jar to the classpath or include it as a Maven dependency

Registration processor module uses the following configuration files that are accessible in this repository. Please refer to the required released tagged version for configuration.

• application-default.properties : Contains common configurations which are required across MOSIP modules.
• registration-processor-default.properties : Contains configurations required or to be overridden for Registration Processor module.

1. Ensure the Config Server is running. For setup and startup instructions, refer to the MOSIP Config Server Setup Guide.

   Note: Verify that all required configuration properties (e.g., DB credentials, IAM credentials, URLs) are correctly updated with your environment-specific values in configuration files.

2. Clone the repository:

git clone <repo-url>
cd registration

3. Build the project:

mvn clean install -Dmaven.javadoc.skip=true -Dgpg.skip=true

4. Start the application:
   • Click the Run button in your IDE, or
   • Run via command:

     java -jar target/specific-service:<$version>.jar
     

Recommended for users who want a quick, ready-to-use setup — testers, students, and external users.

Pull the latest pre-built images from Docker Hub using the following commands:

docker pull mosipid/registration-processor-common-camel-bridge:1.3.0
...

Recommended for contributors or developers who want to modify or build the services from source.

1. Clone and build the project:

git clone <repo-url>
cd registration
mvn clean install -Dmaven.javadoc.skip=true -Dgpg.skip=true

2. Navigate to each service directory and build the Docker image:

cd registration/<service-directory>
docker build -t <service-name> .

Start each service using Docker:

docker run -d -p <port>:<port> --name <service-name> <service-name>

Check that all containers are running:

docker ps

Access the services at http://localhost:<port> using the port mappings listed above.

To deploy Registration Processor services on Kubernetes cluster using Dockers refer to Sandbox Deployment.

API documentation is available here

To learn more about registration processor from a functional perspective and use case scenarios, refer to our main documentation: Click here.

Automated functional tests available in DSL Automation

• To learn how you can contribute code to this application, click here.

• If you have questions or encounter issues, visit the MOSIP Community for support.

• For any GitHub issues: Report here

This project is licensed under the Mozilla Public License 2.0.