FinTech · Identity & compliance
Centralized KYC Platform
One KYC for every financial product, so merchants verify once instead of once per product.
50%faster onboarding
The challenge
A growing suite of financial products each ran its own KYC, and approvals were manual and slow. As merchants adopted more than one product, they repeated verification every time.
The fix was a single KYC platform that every product consumes, with automated third-party verification in place of manual review.
Our Founder's role
- Owned the three-step third-party verification flow (OCR verification, ID proofing and liveness), including the modules and services for each step and the database updates as a KYC moves through them.
How it works
- 01
Data model
Separate tables for business and individual KYC. Individual KYC splits across three tables: critical state (SSO ID, OCR and ID-proofing status), basic profile and employment details. This unifies schemas from several existing KYC apps while leaving room for each to evolve.
- 02
Transactional submission
A submission uploads every document to S3 and splits, validates and saves the details across tables as one unit. Either everything succeeds or nothing is recorded.
- 03
Lifecycle and quotas
A KYC can be sent back for revision at most three times before it must be rejected and resubmitted. Third-party verification calls are capped per KYC and in total. Deleted KYCs are soft-deleted, and their documents move from S3 Standard to Glacier Deep Archive.
- 04
Contract-first service
A Go service (Chi, GORM, Viper) with its API defined in OpenAPI and generated with oapi-codegen, so every consuming product integrates against the same spec.
- 05
Data and migrations
PostgreSQL with versioned Goose migrations. Tested with Ginkgo and mockgen, shipped through Bitbucket Pipelines.
- 06
Asynchronous status
KYC status changes are published to Kafka. Consuming applications subscribe and update their users without polling the platform.
- 07
Elastic on Kubernetes
Horizontal Pod Autoscaling between 3 and 10 replicas, triggered at 80% CPU or memory utilisation.
Engineering decisions
SQL vs NoSQL, decided on constraints rather than fashion
- A document store had real merit: per-product fields that evolve, few strong relationships, and one self-contained document per KYC.
- Team skills, ready PostgreSQL infrastructure and mature Go integration made PostgreSQL the faster, lower-risk path to production. Loose relationships and carefully separated tables kept the flexibility, so schema changes don't force client apps to change.
Kafka over webhooks or polling
- Go, PostgreSQL and Kafka was the organisation's standard stack, with scaffolding repositories ready, a trained team and consumer code already in every client app. Under strict timelines, that outweighed introducing anything new.
- The platform publishes each status change once and doesn't need to know who consumes it. New products subscribe without any change to the KYC service.
Outcomes
- Merchants verify once across all products instead of once per app.
- Roughly 50% reduction in onboarding time, from consolidating repeated KYCs and replacing manual approval with automated third-party verification.
- 30% increase in customer-care agent productivity across verification pipelines.
- Status updates reach every consumer asynchronously.
- Scales automatically from 3 to 10 pods under load.
Technology
- Go · Chi
- Service and routing
- PostgreSQL · GORM · Goose
- Data, ORM and migrations
- OpenAPI · oapi-codegen
- API contract
- Kafka
- Status events
- AWS S3
- KYC documents and archival
- Docker · Kubernetes
- Runtime and autoscaling
- Ginkgo · mockgen
- Testing
- Bitbucket Pipelines
- CI/CD
Contact
Have something you want to build?
Tell us what you're building, or what you'd like to automate. Let's figure out the next step.