Digital Identity Verification & KYC Platform
Verify 360 - KYC & Identity Verification Platform
Verify 360 is a KYC and identity verification platform. It is what a business uses to confirm someone is who they say they are before opening an account. It runs document checks, 3D liveness detection, and location tracking. Each attempt then gets a risk score, so doubtful cases go to a person for review. React and React Native cover the front end. Node.js and MongoDB sit behind them.
Project Overview
Identity verification is a sequence of checks, not one action. A user submits an ID document. Then a liveness check proves a real person is there, not a photo or a screen recording. Location is captured along the way. Third-party identity services get called to confirm the details supplied.
Each check gives off a signal, and no single signal settles anything on its own. The platform folds them into one risk score. A compliance team can then spend its time on the cases that need a human, and leave the clear ones alone.
There are two clients: a React web app and a React Native mobile app. Liveness detection needs a camera, and mobile is where most people finish that step.
My Role
- Built the React web application and worked on the React Native mobile client
- Developed REST APIs on Node.js and Express for the verification flow
- Integrated AWS Rekognition for face and document checks
- Integrated third-party identity verification APIs
- Worked on real-time geolocation capture during verification
- Implemented the risk-scoring logic that flags suspicious verification attempts
The Problem
Verification has to be strict enough to catch fraud and smooth enough that real users finish it. Every extra step costs you genuine applicants. Every weak check lets a bad one through. The hard part is that no single signal settles the question. A document can look valid, a face can match its photo, a location can seem fine, and the attempt can still be fake. So the system had to weigh several separate checks into one answer, and do it while the user sat waiting.
How I Built It
Verification runs as a series of steps. Each one produces a result the next step can use. Users start on the React web app or the React Native mobile app. Mobile carries real weight here, because liveness detection needs camera access and a guided capture flow.
The Node.js and Express backend runs the whole process. It takes the document, calls AWS Rekognition for the face and document checks, then calls third-party identity services to confirm the details supplied. Location is captured as the user moves through the flow, which gives one more signal to weigh.
MongoDB stores the verification records. Every check type and every outside service hands back a different response shape. A document store holds that variation as it arrives, with no rigid schema to squeeze it into.
Risk scoring runs once the checks are done. There is no plain pass or fail. The signals combine into a score, and that score decides whether an attempt clears on its own or lands with a compliance reviewer.
Key Features
Document Verification
An ID document is submitted and checked as the first stage. Everything after this leans on whether that document holds up.
3D Liveness Detection
A liveness check confirms a real person is there, not a photo, a screen, or a recording. It is what gives face matching any meaning. Without it, a printed photo could walk right through.
Real-Time Geolocation
Location is captured while the check is running. It adds a signal that no document check can give you on its own.
Third-Party Identity Verification
Outside identity services check the details a user gives against sources beyond the platform. The result never rests on the submitted files alone.
Risk Scoring
Signals from each check combine into a score, not a simple pass or fail. Odd attempts get flagged for human review. Clean ones clear on their own.
Web and Mobile Clients
A React web app and a React Native mobile app both talk to the same APIs. Mobile carries the liveness step, because camera capture works best on a phone.
Technical Architecture
- React Web & React Native Clients
- REST API (Node.js / Express)
- Verification Pipeline
- AWS Rekognition + Third-Party Identity APIs
- Risk Scoring & MongoDB
Both clients talk to the same REST API, so a check behaves the same whether it starts on web or mobile. The backend runs the pipeline. It takes the submitted document, calls AWS Rekognition for the face and document checks, calls third-party identity services for the supplied details, and records location along the way. Results land in MongoDB. Risk scoring then weighs the signals and decides whether an attempt clears or goes to review.
Engineering Decisions
Risk scoring over a single pass-or-fail check
- Why
- No single check settles it. A document can look valid while the other signals do not add up. Rolling them into one score keeps real users moving and sends only the doubtful cases to a person.
- Trade-off
- A score needs thresholds, and a threshold is a judgment call. Set it too tight and real users get blocked. Set it too loose and the review queue fills with cases nobody needed to see.
React Native alongside the web client
- Why
- Liveness detection needs camera access and a guided capture flow. Both work far better on a phone than in a browser. Most users finish that step on mobile anyway.
- Trade-off
- Two clients to build and keep in step. One shared REST API kept the logic in a single place, so nothing had to be written twice.
MongoDB for verification records
- Why
- Check types and outside providers return different response shapes. A document store holds that variation as it is. A fixed schema would have flattened every provider's output to fit.
- Trade-off
- The app has to keep records consistent on its own. The database will accept shapes nobody intended, so every write has to be careful.
Managed services for face and document checks
- Why
- AWS Rekognition and the established identity providers already do this work well. Matching that standard alone would take years. Compliance work also benefits from services built for the job.
- Trade-off
- It creates a dependency on outside services. Their uptime, their speed, and their pricing all become part of how the platform behaves.
Challenges and Trade-offs
- Outside services can be slow or briefly down, and all of this happens while a user waits. Failed calls had to be treated as a normal case, not an exception.
- Risk thresholds balance fraud against friction. Every change hits both sides. Tighten the score and you catch more fraud, but you also stop more real users.
- Two clients and several outside services make for a wide surface area. Keeping the logic in the backend, well away from the clients, is what kept it manageable.
Technology Stack
Frontend
- React
- React Native
Backend
- Node.js
- Express.js
- REST API
Database
- MongoDB
Verification Services
- AWS Rekognition
- Third-party identity APIs
- Geolocation
Outcome
- A KYC platform covering document verification, 3D liveness detection, and geolocation capture
- Risk scoring that flags suspicious attempts for compliance review instead of a single pass-or-fail result
- Integrations with AWS Rekognition and third-party identity verification services
- Web and mobile clients running on the same verification APIs
- Compliance workflows supporting 100+ client verifications
What I Learned
- When a decision rests on several separate signals, a score beats a yes or no. It keeps the uncertainty visible.
- Leaning on outside services means their failures become your behavior. Slow and missing responses need designing for, not filing under edge cases.
- Shared logic in the backend is what makes two clients sustainable. Copy the rules onto each platform and they will drift apart, guaranteed.
Third-party integrations, REST APIs, and production React work run through most of what I build. See my API and integration experience.
Other production platforms and full-stack builds sit next to this one. Open the full list of projects.