Most KYC systems are built as isolated checkpoints.
A user uploads an ID document to one service, waits for approval and repeats the same process when joining another platform. The verification may already have been completed successfully, but the result usually remains locked inside the first provider's database.
For users, each repeated check can take another 15 to 20 minutes. For businesses, a single verification may cost between $5 and $15 while adding friction to the onboarding funnel.
It also creates a data protection problem. The same sensitive documents can end up stored by many separate companies.
Kimlic started with a different model:
Verify the user once, create a reusable credential and allow other services to validate the required proof without asking for the same documents again.
I am the founder and CTO of Pharos Production. Our partnership with Kimlic began in 2018. We worked with the client to design and build a blockchain-based KYC and digital identity platform for Web3 and FinTech products.
The production system now processes more than 10,000 identity verifications per day with 99.8% verification accuracy.
This article explains the public architecture behind the platform, the decisions that shaped it and the lessons we learned while building reusable identity infrastructure.
The product challenge
Kimlic needed to connect three requirements that often pull an identity platform in different directions.
The first was reuse. Users should not have to complete the same verification process for every service.
The second was privacy. Reuse should not require sensitive personal information to be copied across multiple databases or published on a blockchain.
The third was compliance. Businesses still needed a reliable way to request a verification, validate its current status and preserve an auditable history of the process.
The platform also had to operate under real production load:
- KYC and AML requirements across at least four jurisdictions
- More than 10,000 verification flows per day
- More than 3,000 concurrent verification sessions
- Response times below three seconds
- 99.9% platform uptime
- 99.8% verification accuracy
- Secure APIs for external FinTech and Web3 products
This was not only a smart contract project.
It required blockchain engineering, identity workflow design, high-concurrency backend development, cloud infrastructure, auditability and integration APIs to function as one system.
Blockchain as a proof layer
Using blockchain for KYC does not mean placing passports, addresses or other personal documents on a public ledger.
That would create an obvious privacy problem. Blockchain data is difficult to remove and can remain visible long after the original business purpose has ended.
Kimlic uses the blockchain as a verification and proof layer.
Users complete the identity process through the platform. The system creates cryptographic evidence of the verification while limiting the disclosure of sensitive personal data.
The reusable credential can then be presented to another service. That service validates the required proof instead of asking the user to upload the same identity documents again.
At a simplified level, the flow looks like this:
User starts identity verification
|
v
Kimlic verification workflow
|
v
Identity status and evidence are created
|
+-------+--------+
| |
v v
Metadata and Cryptographic
audit records blockchain proof
| |
+-------+--------+
|
v
User grants access to a service
|
v
Service validates the KYC proof through an API
This division is important.
The blockchain provides tamper-resistant evidence while the application layer manages identity workflows, consent, access and compliance-related state.
The result is a portable credential without turning the blockchain into a public personal-data database.
A reusable credential is more than a boolean value
It is tempting to represent KYC as one field:
verified = true
A production identity platform needs a much richer model.
The meaning of a verification can depend on when it was completed, which checks were performed and which jurisdictional requirements applied. Its status may also change after the initial decision.
A reusable credential therefore needs a lifecycle.
The platform must track the current verification state, the evidence supporting it and the consent under which another business can access it. It also needs an audit trail of important state changes.
This is one reason we separated the user-facing proof from the complete internal workflow.
A partner may only need to know whether an acceptable verification exists. The platform still needs the underlying metadata and audit history required to support that answer.
The score, status or proof presented to an external product is only the visible surface of a larger identity system.
The public architecture
The main public technology stack behind Kimlic includes:
- Elixir and Erlang
- PostgreSQL
- React and Next.js
- AWS
- Kubernetes
- Terraform
- Blockchain-based cryptographic proofs
A simplified architecture looks like this:
User identity portal
React / Next.js
|
|
Business dashboard and APIs
React / Next.js
|
v
Elixir and Erlang services
Identity workflows and verification logic
/ | \
/ | \
v v v
PostgreSQL Blockchain proof Integration APIs
metadata, and credential for FinTech and
states and validation Web3 products
audit logs
\ | /
\ | /
+-------------+--------------+
|
v
AWS and Kubernetes
|
v
Infrastructure as code
Terraform
This is intentionally a high-level view. It excludes proprietary verification logic, security controls and implementation details that cannot be published.
Why we used Elixir and Erlang
Identity verification involves many concurrent workflows.
Different users can be submitting data, waiting for checks, receiving updated statuses or granting access to business clients at the same time. Each workflow can move independently and may depend on external operations.
The backend also needs to remain stable when an individual process or integration fails.
Elixir and Erlang provide a strong foundation for this model. They are well suited to systems with high concurrency, isolated processes and long-running state transitions.
For Kimlic, the backend is responsible for:
- Identity workflow orchestration
- Verification logic
- API services
- Real-time identity status updates
- Event-driven communication
- Integration with the blockchain proof layer
- Communication with user and business interfaces
The key benefit was not language syntax.
The important factor was the ability to isolate work, process many verification sessions concurrently and recover from failures without treating every exception as a platform-wide incident.
That became particularly relevant as the system scaled beyond 3,000 concurrent verification sessions.
Event-driven identity workflows
A verification process contains a sequence of state changes.
A user initiates the process. The platform receives the required information. Verification logic evaluates it. The identity status changes and the result becomes available to the user or an authorized business.
Processing all of this as one large synchronous request would create several problems.
The request could remain open while the platform waits for another component. A temporary failure could force the complete workflow to restart. Higher traffic could also make the API layer responsible for too much long-running work.
Kimlic uses event-driven communication and scalable messaging patterns for workflow and state changes.
This lets different parts of the platform progress independently.
A request can be accepted, processed and updated without forcing the user interface to hold one connection open for the complete verification lifecycle.
The architecture also makes it easier to isolate failures. One delayed operation does not need to stop unrelated verification sessions.
The broader lesson is useful for any regulated workflow:
Model the business process as a sequence of durable state transitions instead of one oversized request-response operation.
PostgreSQL as the operational source of identity state
The blockchain proof is only one part of the system.
Kimlic also needs a reliable operational record of identity metadata, current verification states and audit events.
PostgreSQL serves as the primary data store for that information.
This separation gives each layer a clear responsibility:
| Layer | Responsibility |
|---|---|
| PostgreSQL | Identity metadata, workflow states and audit records |
| Blockchain | Cryptographic proof and tamper-resistant verification evidence |
| Elixir and Erlang services | Workflow orchestration, verification logic and APIs |
| Next.js interfaces | User consent, identity management and business access |
| AWS and Kubernetes | Availability, deployment and horizontal scaling |
| Terraform | Repeatable infrastructure provisioning |
Keeping operational data outside the blockchain also gives the application more control over access patterns and internal workflow changes.
The blockchain does not need to become the primary database for every identity operation. It is used where its properties add value.
Privacy-preserving data sharing
Reusable KYC creates a difficult question:
How can another service trust the verification without receiving every piece of personal data collected during the original process?
Kimlic addresses this through selective proof sharing and user consent.
The user manages the verified identity through a secure interface. When another service requires KYC, the platform shares the necessary proof rather than broadly exposing the complete identity record.
This model reduces unnecessary document duplication.
It also creates a clearer access boundary. The consuming service requests a specific verification result while the user retains control over the sharing process.
From an architecture perspective, privacy depends on more than encryption.
A privacy-preserving identity platform also needs to control:
- Which data is collected
- Where each category of data is stored
- Which service can request a proof
- Which user action grants access
- Which events must be recorded for an audit
- Which information the receiving business actually needs
The safest sensitive record is often the one that never needs to be copied into another system.
APIs are part of the compliance product
Kimlic was designed for use by FinTech companies, exchanges and Web3 applications.
That meant the integration layer could not be treated as a secondary feature.
External businesses needed secure APIs through which they could:
- Request a KYC verification
- Check the current identity status
- Validate an existing proof
- Integrate the result into onboarding
- Maintain a traceable verification workflow
The API is where the reusable identity model becomes commercially useful.
Without a stable integration layer, the credential would remain limited to the Kimlic interface. Each new partner would require custom development and the platform would struggle to grow beyond its original use case.
We therefore treated API design as part of the core architecture.
The business application should not need to understand the complete internal verification pipeline. It needs a predictable contract for requesting a check and receiving a result.
That contract also needs to remain stable as internal verification logic evolves.
Separate interfaces for users and businesses
The platform serves two different audiences.
Users need to complete verification, view their identity status and manage consent.
Business clients need to request proofs, review verification results and integrate KYC status into their own systems.
Kimlic provides React and Next.js interfaces for both groups.
The user experience focuses on identity management and consent. The business experience provides access to dashboards and APIs for requesting and validating proofs.
Keeping these concerns separate helped us avoid exposing the full internal workflow to every participant.
A user does not need a compliance operations dashboard. A business client does not need access to the user's complete identity interface.
Each audience receives the surface required for its role.
Compliance had to influence the architecture
Compliance cannot be added to an identity platform after the technical design is complete.
The verification model affects data collection. Data retention affects storage. Audit requirements affect event logging. Jurisdictional rules affect workflow behavior and the information a business needs to validate.
Our engineers worked closely with Kimlic's compliance team while designing the platform.
The objective was to ensure that technical decisions reflected the KYC and AML requirements of the target jurisdictions from the beginning.
This included the relationship between:
- Verification evidence
- Identity status
- Consent
- Auditability
- Blockchain proofs
- Business access
The platform achieved a 100% compliance audit pass rate after deployment while operating across four jurisdictions.
That outcome came from treating compliance as an architectural input rather than a final checklist.
Scaling the platform on AWS and Kubernetes
Identity onboarding traffic is not always consistent.
A new partner launch, marketing campaign or customer migration can create a sudden increase in verification sessions. The infrastructure needs to absorb that increase without turning KYC into an onboarding bottleneck.
Kimlic runs on AWS and Kubernetes.
The containerized architecture allows services to scale as load increases. Workloads can be deployed and updated independently while Kubernetes handles orchestration and service recovery.
Terraform manages infrastructure as code.
This gives the team a repeatable way to provision and change infrastructure while reducing reliance on manual cloud configuration.
The production platform supports:
- More than 3,000 concurrent verification sessions
- Response times below three seconds
- 99.9% uptime
- Automatic scaling during peak onboarding periods
The value of this infrastructure is visible in the user funnel.
A reliable verification system keeps onboarding moving during high demand. An unreliable system converts infrastructure pressure into abandoned registrations.
What Pharos Production delivered
Pharos Production worked with Kimlic across the complete technical platform rather than delivering one isolated component.
Our contribution included:
- Blockchain-based credential and proof architecture
- Smart contract engineering
- Identity verification backend services
- Event-driven workflow processing
- KYC and AML integration logic
- PostgreSQL data and audit architecture
- APIs for external FinTech and Web3 products
- User and business web interfaces
- AWS and Kubernetes infrastructure
- Terraform-based infrastructure automation
- Performance and production scaling
The work required coordination between blockchain engineers, backend developers, frontend developers, DevOps specialists and compliance stakeholders.
That cross-functional delivery model was necessary.
A smart contract alone cannot run a KYC platform. A verification backend alone cannot create reusable credentials. A compliant workflow still needs reliable infrastructure and a usable integration layer.
The platform only works when all of those components operate as one product.
Production results
The public results from the project include:
| Metric | Result |
|---|---|
| Daily identity verifications | 10,000+ |
| Verification accuracy | 99.8% |
| Concurrent verification sessions | 3,000+ |
| Response time | Below 3 seconds |
| Platform uptime | 99.9% |
| Target jurisdictions | 4 |
| Compliance audit pass rate | 100% |
| Reduction in onboarding time | 60% |
The measured onboarding completion rate increased from 62% to 89%.
Verification volume on the same measured workload grew from 20,000 to 140,000 flows per month compared with the pre-optimization baseline.
These results show the connection between architecture and business performance.
Reducing duplicate checks shortens onboarding. Reliable processing prevents traffic spikes from blocking users. Reusable proofs lower the amount of work required when the same identity moves between services.
What we learned
1. Do not use blockchain as a personal-data database
The blockchain should store the proof required for verification rather than a public copy of the underlying identity documents.
Immutability is useful for evidence. It becomes a liability when applied to sensitive data that should not remain permanently exposed.
2. Design the credential lifecycle before choosing the stack
A reusable identity is not a static record.
Define how it is created, updated, validated and shared. Also define which state changes must remain auditable.
Those decisions shape the backend, data model, APIs and blockchain layer.
3. Separate proof from operational state
The blockchain proof and the operational identity workflow serve different purposes.
Keeping them separate allows each layer to use the storage and access model appropriate to its role.
4. Treat consent as a system capability
Consent cannot exist only as text next to a checkbox.
The platform needs to know which user authorized which proof to be shared with which service. That decision must be reflected in the product flow and audit history.
5. Keep long-running work outside synchronous API requests
Identity checks may depend on several processing steps.
An event-driven workflow prevents the public API from becoming responsible for waiting on the complete lifecycle.
6. Build integration contracts early
Reusable credentials only create network value when other products can consume them.
Stable APIs and clear business-facing workflows should be designed alongside the identity engine.
7. Bring compliance into architecture discussions
Compliance requirements influence data storage, logging, workflow states and access control.
Involving compliance specialists after implementation usually means redesigning decisions that were already embedded throughout the platform.
Client feedback
Kimlic's CEO highlighted both the production results and the contribution of our engineering team:
“Their smart contract expertise and understanding of KYC compliance were critical to our success.”
For teams evaluating Pharos Production as a development partner, the complete Kimlic case study includes the public technology stack, project results and client feedback.
Final thought
The main value of blockchain-based KYC is not putting identity data on-chain.
It is making a verified result portable and independently provable while keeping sensitive information under controlled access.
Kimlic turned that model into a production platform.
Users can verify once and reuse the result. Businesses receive a compliant API instead of another manual document flow. The infrastructure supports thousands of concurrent sessions while preserving the auditability required for regulated identity workflows.
For Pharos Production, Kimlic demonstrates how blockchain engineering, high-concurrency backend development and compliance-driven architecture can be combined within one real product.
Teams building a similar KYC, digital identity or regulated onboarding platform can review the full technical case and contact us through the project page.
Which part of reusable KYC creates the harder engineering problem in your experience: privacy, credential portability or regulatory consistency?
Top comments (0)