Before we get into what IDPylon does, it helps to understand where we came from. Adrian and I spent several years working on compliance tooling at two different fintech companies. One was a digital lending platform, the other was a payments infrastructure company. Different products, different regulatory contexts, but the same underlying frustration: the KYC vendors we integrated with treated every applicant as if they were identical.
Someone applying for a $200 prepaid card got the same document scan plus liveness check as someone opening a $50,000 margin account. A user in a geography with low historical fraud rates went through the same friction as one in a region with known document forgery rings. None of that made operational sense, and it cost both companies real money in the form of drop-off, manual review backlogs, and unnecessary vendor API costs.
What We Kept Wishing For
The thing we wanted was not complicated to describe. We wanted a system that read available risk signals before deciding what checks to run, rather than applying a fixed policy regardless of context. Document type, device fingerprint, geography, behavioral signals from the session, prior attempt history: these are all inputs that should influence which verification path an applicant takes.
What we kept building instead were brittle if-else chains layered on top of single-vendor KYC integrations. We would add country-specific routing rules. Then we would add product-tier rules. Then someone from compliance would ask us to add a rule about flagged email domains. Eventually the routing logic lived scattered across three microservices and was nearly impossible to audit, let alone change safely.
We tried to solve this twice at our respective companies before deciding to build the tool independently. The internal builds both got deprioritized. The problem was real, the solution was well-understood in principle, but it was always a roadmap item that got bumped for product features. That is a common pattern in fintech: compliance infrastructure improvements get deferred until they become a regulatory finding or an operations crisis.
The Core of What IDPylon Does
IDPylon is an orchestration layer that sits between your application and the individual identity check providers. When you initiate a verification session, IDPylon ingests risk signals and decides which checks to run, in what order, and how to combine their outputs into a final decision.
A low-risk session where the device is known, the document is a common domestic type, and there are no prior failed attempts might clear with a document scan alone in under two seconds. A session with an elevated risk signal set (unfamiliar device, document from a high-risk jurisdiction, behavioral patterns suggesting scripted input) routes through additional checks including liveness detection. Sessions that exceed the automated confidence thresholds route to your compliance team's manual review queue with all collected evidence attached.
The orchestration logic is configurable. You define risk thresholds, choose which check providers to use for each check type, and set escalation policies. We maintain the routing engine. You keep control of the policy that drives it.
What We Did Not Build (On Purpose)
We are not a document verification provider. We are not a liveness vendor. We do not own the biometric capture stack. We integrate with check providers and route sessions through them. This is a deliberate choice: the document and liveness vendor market is mature and competitive, and building proprietary capture and classification models would take years and significant capital we do not have as a bootstrapped team.
What we built instead is the layer that the existing vendors cannot provide because it sits above any single vendor: the stateful routing engine, the session history that enables step-up verification and re-verification triggers, the unified audit trail across check types, and the API that returns a single structured decision regardless of which checks ran underneath.
We are not saying that building your own check models is wrong. For a large platform with the data volume to train on and the engineering resources to maintain, owning that layer can make sense. We are building for companies where the routing and orchestration problem is the urgent one, not the model quality problem.
The Technical Decisions Worth Noting
We built the session model to be stateful from the start. Every verification session has a persistent record: signals observed, checks dispatched, results returned, and the final decision with its confidence score and reason code. This matters for two reasons. First, it enables step-up verification: if a user comes back and their risk profile has changed, IDPylon can see that they previously verified with a lower check level and trigger the appropriate additional check automatically. Second, it makes the audit trail coherent. When your compliance team exports session records for an examiner review, every decision is traceable.
We also made a deliberate choice to keep the API response envelope consistent regardless of what ran underneath. A session that cleared with document verification only returns the same response structure as one that ran document plus liveness plus a sanctions screen. The calling application does not need to know which checks executed. It receives a result, a confidence score, and if relevant, a reason code for escalations or failures. This simplifies the integration significantly and makes it easier to change check provider selection or routing policy without touching application code.
What Comes Next
We are live with document verification and liveness orchestration. AML screening and watchlist checks are in the platform and available on the Growth and Scale tiers. We are working on KYB (Know Your Business) orchestration, which introduces a different challenge: the data inputs are more varied, the check providers are more fragmented, and the regulatory obligations differ by jurisdiction in ways that simple document-plus-liveness verification does not encounter.
The blog will document what we learn as we build. We have specific posts planned on risk-based verification design, the practical differences between AML screening and KYC identity verification, and what it actually takes to build an onboarding flow that satisfies both FinCEN CDD requirements and a reasonable conversion rate target.
If you are working on a similar problem, the free tier is available without a credit card. The first 500 verification sessions are covered. We are a small team and we respond to [email protected] directly.