A sandbox environment for Regula IDV Platform can be ready in about 20 minutes, with preconfigured verification workflows you can try right away. Moving into production means setting up the platform in your own environment, connecting it to the systems you already use, and making sure the complete setup works as intended.
What does that involve in practice, and how long does it take? We asked Regula's implementation engineers to walk us through the process, using examples from real customer projects to show what happens at each stage and where the biggest differences in implementation effort come from.
Identity verification platform implementation at a glance
With Regula IDV Platform, the path to production depends on how much customization the project requires. We've seen two common approaches:
-
Template-based implementation. Customers can deploy the platform in their own environment and use a preconfigured workflow, such as KYC, with minimal adjustments. With straightforward requirements and integrations, the setup can be handled by the customer's technical team.
-
Tailored implementation. Projects involving complex infrastructure, custom verification logic, or multiple integrations require more planning and engineering. Regula's Professional Services team can help with requirements, deployment, workflow configuration, integrations, and testing.
Both approaches cover the essential steps needed to get the platform into production, but the amount of work at each stage differs. Some activities can also run in parallel, particularly environment setup, workflow configuration, and integrations.
A workflow configuration stage can be kept to a minimum if the client uses preconfigured scenarios within Regula IDV Platform.
Who should be on your implementation team?
Customers can deploy and manage Regula IDV Platform with their own technical teams, with Regula available for configuration review and troubleshooting. For projects that require more hands-on engineering, Regula's Professional Services team can take a more active role.
Regardless of the approach, based on our experience so far, two types of expertise are needed on the customer’s side:
-
Someone who understands the business process being implemented
-
Someone who understands how the platform needs to fit into the technical environment
The business-side owner should understand how the process works today, what needs to change, and what the new workflow should accomplish. The technical contact should be able to answer questions about infrastructure, integrations, and access.
When the Professional Services team is involved, Regula brings in four core roles: a delivery manager, solution architect, QA engineer, and DevOps engineer. A designer may also join if the project requires branding or UI adjustments.
“We've worked with very different teams. In one project, our main contact was an IT security lead. In another, one person handled both business and technical questions. In larger projects, we may need to work with several departments, so having a project champion who can bring the right people together really helps.”
What needs to be defined before deployment?
Before deploying an identity verification platform, the team needs to define what it is expected to do and what it must connect to. That means collecting both business and technical requirements:
-
Expected verification volumes
-
Deployment environment
-
Security constraints
-
Accepted documents
-
Decision logic
-
Systems that need to send or receive data.
These requirements directly affect the setup. Expected traffic, for example, influences how the platform should be sized and scaled. Internal security rules may determine where it can run, which services can communicate with each other, and how much access Regula engineers can get during deployment and troubleshooting, if needed.
Some customers already have part of this information documented in an RFI or RFP. Others work through the requirements with Regula's engineers during implementation.
In projects involving Regula's PS team, the requirements stage produces three documents:
-
Technical requirements document: Defines the business and technical requirements for the implementation.
-
Sequence or swimlane diagram: Maps the verification process, including its steps, decision points, and possible outcomes.
-
Integration requirements document: Defines how the platform will communicate with the customer's systems.
Mapping the verification process before implementation helps teams agree on how the platform will interact with existing systems and identify potential integration challenges early.
How long does the environment setup take?
For a typical production deployment, environment setup takes about two to five working days. This includes installing the platform, configuring it for the expected load, validating the setup, and resolving any infrastructure or security-related issues.
The exact setup process depends on the customer’s environment.
Regula IDV Platform can be deployed in different cloud environments or on the customer’s own infrastructure. However, the choice of a cloud provider isn't necessarily what makes the biggest difference. Security policies, network rules, access restrictions, and the way internal services communicate usually have a greater impact on the timeline.
Case in point
Recent projects illustrate the difference. In one project, the customer deployed the platform themselves, while Regula reviewed the configuration and helped the customer fine-tune it. The environment was ready in under four days.
In another project, Regula engineers had no direct access to the customer’s systems or logs because of their internal security policies. Troubleshooting had to rely on log fragments and information shared by the customer, which extended the setup to almost a month.
How are verification workflows configured?
Regula IDV Platform includes ready-to-use workflows for common identity verification scenarios. For example, the preconfigured General KYC workflow covers document OCR, RFID chip reading, liveness detection, and face matching. Verification results are displayed within the session.
If the customer only needs to notify their backend when a session is complete, a webhook can be configured separately using the platform's built-in tools. This takes just a few minutes and doesn't require developing a custom workflow.
For more specific business requirements, the verification logic can be adapted: which checks run at each step, what conditions trigger different branches, what information the user provides, and what outcome the platform returns. The sequence diagram prepared during requirements gathering serves as the blueprint.
In projects involving Regula's Professional Services team, workflow configuration is typically estimated at around one week, although the actual time depends on how extensively the existing workflow needs to be adapted.
“We worked with a financial services company that wanted to verify new users during onboarding. They deployed the platform themselves, while I configured a workflow that read identity documents, performed liveness and face matching, and compared the extracted data with their CRM records.
Depending on the parameters they passed to the platform, we could skip certain checks or decide which documents to accept based on what was already in their CRM. We also used webhooks for part of the CRM integration, while the customer’s systems retrieved other data directly from verification sessions.
I configured the workflow in about two weeks, and after testing, the first version went into production within a month.”
The user-facing experience can also be customized through white-label branding, supported languages, on-screen instructions, and hints that guide users through verification.
Branding is usually a relatively small part of the implementation; in current project estimates, it takes about a day.
A demo UI variant prepared for a customer during Regula IDV Platform implementation.
What if your project requires additional functionality not available in the platform yet?
Ideally, capability gaps surface during requirements gathering. Some, however, only become obvious once the agreed workflow is being configured in the platform. At that point, the implementation team checks whether the requirement can be met in another way using existing capabilities or calls for a new product feature.
If the requirement is specific to a single workflow and can be addressed through a different approach, the team adjusts the implementation.
If Regula's product team determines that the requested functionality would be useful beyond the individual project, it may be added to the platform. The customer then receives a release plan indicating when the feature is expected to become available.
Which customer requests have already become platform capabilities?
-
Cross-device continuation. A customer needed users to switch between devices during verification.
-
Offline data collection. A customer requested the ability to collect data through Regula's mobile SDK without an internet connection and upload it to the platform later, once connectivity is restored.
-
Active-active disaster recovery. A customer requested an active-active configuration for an on-premises deployment to improve resilience.
How are integrations handled during implementation?
Once a verification session is complete, the customer's systems need to receive the result and act on it. For example, in an account recovery process, a successful identity check may allow the system to proceed with a password reset.
The integration requirements document prepared earlier defines how this exchange should work — whether the platform sends data via webhooks or callbacks, or whether the customer’s system retrieves the result itself.
“Integration timelines really depend on what needs to be connected. In one project, we configured an API callback in just 15 minutes. In another, it took about five days to develop custom scripts for the customer's internal systems. Integrating a third-party SDK is a different scope of work altogether. In one recent project, that took us about a month.”
How is platform implementation tested before go-live?
Testing is planned before implementation is complete. During the requirements stage, Regula and the customer agree on what needs to be tested and which scenarios the test scope should cover. Then, while the platform is being configured, QA prepares tests for that particular implementation.
Before go-live, the setup is validated in three stages:
-
Regula-side testing. The team tests the workflow and integrations in its own environment, including by simulating the customer’s systems.
-
End-to-end testing in the customer environment. The complete setup is tested with the customer's actual infrastructure and connected systems to confirm the agreed workflow operates as expected.
-
Customer acceptance testing. The customer checks that the implementation meets its requirements, using Regula's test results, its own QA process, or both.
As a working estimate, Regula currently allows about a week for testing, but customer acceptance can extend the timeline to a few more weeks.
What happens after the identity verification platform goes live?
Once the customer approves the implementation, the platform can go live. At Regula, every go-live is followed by hypercare: a period of closer support from the implementation team.
Hypercare typically lasts around three months, with the most intensive support immediately after launch and the level of involvement gradually decreasing as the setup stabilizes.
During the first days in production, the Regula team stays in close contact with the customer to help resolve any unexpected issues. For example, if the share of Not Verified sessions rises, engineers investigate whether this reflects normal user behavior, attempted fraud, or a scenario that needs adjustments to the configured workflow.
At the same time, the implementation artifacts are handed over to the Regula support team, so that support engineers have enough context to provide targeted assistance after hypercare ends.
Regula also provides training for the people who will operate and support the platform on the customer’s side. These may include IT specialists, administrators, support staff, and teams responsible for reviewing verification sessions.
So, how long does implementing an identity verification platform take?
The timeline depends largely on how much work is needed beyond the platform's ready-to-use capabilities. A rollout based on preconfigured workflows and standard integrations can reach production in a few days to around two weeks. Projects involving tailored workflows, complex integrations, or restrictive enterprise environments may take six to ten weeks or longer.
Here's how the two implementation scenarios compare, based on Regula's project planning estimates.
| Stage | Template-based implementation | Tailored implementation |
|---|---|---|
| Requirements and planning | 2–5 days to select a template workflow and confirm accepted document types and verification rules | 2–3 weeks to prepare the technical specification, workflow diagram, integration requirements, and test scope |
| Environment setup | 1–5 days | 2–5 days (can be potentially longer due to a client’s security and access policies) |
| Workflow configuration | 1–3 days | ~1 week, depending on the extent of customization |
| Integrations | Around 1 day for a standard API callback | 4–5 days for custom scripts; third-party SDK integration can take 3–4 weeks |
| Testing and acceptance | 2–5 days | 1–2 weeks |
| Estimated time to go-live | 1–3 weeks | 6–10 weeks |
Planning your own rollout?
How difficult that journey is depends heavily on what you already have in place. Some teams move quickly because their infrastructure and ownership are relatively simple. Others need more time to work through security restrictions, existing/internal systems, or internal dependencies.
If you’re considering Regula IDV Platform, you don’t need to arrive with a finished implementation plan. We can help you work through the use case, infrastructure, integrations, and constraints, and figure out what a realistic rollout would look like.
Talk to our team about your implementation.
