Most onboarding stacks were never designed. A document reader here, a sanctions feed there, an address check for the one country that needed it, each the right call at the time. IDCanopy is the layer over all of it: one contract, one API, one policy engine, whether you buy it direct or through the partner who brought you here.
A request arrives. Before any check runs, the policy engine already knows three things: which market the user is in, which rules apply to this product, and what your risk appetite is for this case.
Then it picks. Not a fixed chain. The document reader that performs best for this issuing country. The address source that actually covers this postcode. A step-up only if the first answer was ambiguous.
Every signal and every version of the rules that fired is logged against the decision it produced, capability by capability, so the reasoning behind any one decision is one query away, not a reconstruction project.
| A stack of point tools | IDCanopy | |
|---|---|---|
| Contracts | separate contracts and renewals | one contract |
| Integration | a separate integration for each check | one integration |
| Rules | distributed across tools | one policy engine |
| Decision logging | reconstructed after the fact from scattered logs | logged against the decision as it happens, per capability |
| Coverage | changes tied to vendor projects | configured behind the same interface |
The right-hand column is not a better product. It is the same checks, sequenced by something that knows what the last one returned. And it sits underneath whatever relationship brought you here, not instead of it.
Document and NFC reading, biometrics, address, phone, open banking identification and eID, sequenced per market.
KYBRegistry retrieval, UBO resolution, risk-class templates, ongoing monitoring.
Identity & SigningIssue and reuse eIDs, qualified signing, authentication, embedded identity inside someone else's app.
Risk IntelligenceScreening, adverse media, fraud signals, open banking data, OSINT, and the tools your analysts work in.
Some problems are too big to be a feature.
Aletheia asks whether a document makes sense, not whether it looks right. Poros retrieves and checks company data, resolves ownership, verifies bank ownership and assembles exceptions for review.
Both run inside the platform. Both work without it.
More than 20,000 document templates.
More than 200 trade registers and company profiles across the wired sources.
Open banking across 21 countries, with 80 percent bank coverage and 567 million accounts.
eIDAS-compliant QES across the EU, with cross-border recognition.
IDCanopy holds no certifications. Our data centres and providers are ISO/IEC 27001 certified, and the platform uses EU data residency. We enable customers to meet their DORA and NIS2 obligations. All our biometric solutions are at least iBeta level 2.
One REST API. SDKs where you want the flow hosted, an interface where you want to build it yourself, and a back office where your analysts work.