Skip to content

IDV Platform Architecture

This article provides an overview of the architecture behind Regula Identity Verification (IDV) Platform—a modular and scalable system built to support secure and flexible identity verification workflows.

Overview

At a high level, the Platform is composed of two major parts:

  • Backend handles all data processing.
  • Frontend serves as the data collection terminal. It includes Web and Mobile components, as well as direct API-based integration.

Security and Deployment Considerations

IDV is designed to be deployed within a private network, often referred to as a DMZ — demilitarized zone. In such deployments, IDV operates fully behind the scenes, and all components remain internal.

For communication with external clients, an external frontend is required. This could involve a load balancer or reverse proxy (for example, NGINX, Traefik, or others). This frontend typically handles:

  • SSL Termination ensuring that secure (HTTPS) connections from clients are decrypted before passing requests to internal services.
  • Traffic routing to internal components like the API.

Load Balancer

External Interface: Client Integration

The IDV Platform client interface can be either a Web application or a Mobile application. This integration is handled through the IDV SDK, much like the Document Reader SDK integration.

The functionality of the Platform can be broadened by additional Regula SDKs:

The SDK interacts with the IDV backend, which is hosted in a secure, internal network.

DMZ

Core Backend Components

Once the request enters the backend system, the IDV Platform manages processing through its main internal services, which are the following:

  • API is the main entry point for incoming requests. It handles authentication and routes the request to the appropriate internal modules. It also acts as a secure gateway to the Document Reader SDK and Face SDK, which otherwise lack built-in authorization.

  • Workflow executes the core business logic of the Platform by running customizable verification scenarios. Each workflow instance processes data based on a predefined verification flow. Workflows are scalable and can be multiplied to handle larger loads.

  • Scheduler manages background tasks like data cleanup and other periodic operations.

  • Audit is a dedicated component for writing and storing audit logs to ensure traceability and compliance.

  • Indexer is responsible for preparing identity-related data for fast retrieval and search. It builds and maintains indexes that allow the Platform to quickly locate and match records during verification, even across large datasets.

Frontend and backend components communicate via a Message Bus. The Platform was tested using RabbitMQ as the message broker.

Core Backend Components

Scalability

Each IDV component is designed to be independent and horizontally scalable:

  • API and Workflow services can be scaled based on load.
  • Scheduler ensures regular maintenance and job execution.
  • Audit operates independently to log Platform activities.
  • Indexer scales with data size, ensuring that searches and lookups remain efficient.
  • Vector Database can be scaled to handle large volumes of biometric templates and ensure efficient similarity searches.

Storage

IDV relies on three storage mechanisms:

  • Database: Structured data is stored in MongoDB, which supports flexible schema designs.

  • Data Storage: Binary data is stored either in S3-compatible storage or filesystem-based (FS) storage, depending on the deployment choice.

  • Vector Database stores special numerical representations of biometric data, such as a person’s face or document features.

Data Storage

API Authorization and Security Layer

Unlike standalone SDKs like the Document Reader SDK and Face SDK (which do not implement any access control), the IDV API introduces an authorization layer. This is critical because:

  • Requests to IDV must be authenticated.
  • Unauthorized access to sensitive identity verification tools and data is blocked at the API layer.

This architectural decision ensures that only authorized users can access document processing and facial recognition functionality, which is essential for secure deployment, especially when services are exposed over the internet.