Solutions
Points in a business process where verifying identity was a bottleneck, or where verification was not possible at all. We set out the regulatory basis alongside the flow.
Identity verified once, reused at the next institution — with no personal data moving between them.
Customers photograph the same ID document again every time they move to another financial institution. Each institution verifies the same person from scratch.
OID4VCI 1.0 · OID4VP 1.0 · SD-JWT VC · Token Status List
Entitlement granted to a verified holder, not to a wallet address.
An issuer has to know who holds the token, but all that is visible on-chain is an address. An address is not a person.
SD-JWT VC · Token Status List
Income and employment evidence arrives as a signed credential instead of a document.
Most of the documents a loan assessment needs are facts that have already been issued somewhere else. The customer collects them and submits them again.
SD-JWT VC selective disclosure · OID4VP 1.0
The institution proves itself to the customer, not the other way round. Verification stops resting on a person's judgement.
In voice phishing the party that never gets verified is the institution. There is no way to check that the caller really is the bank.
OID4VP 1.0 · client_id_prefix=x509_hash
Attach a verification service instead of building one. Keeping up with the standards is our side of the deal.
Build it yourself and you own signature verification, key binding, status lookup, trusted-issuer management and every protocol revision that follows.
OID4VP 1.0 FINAL · DCQL · HAIP 1.0
Identity issued in Korea, accepted in the EU. Implementing the same profile is enough.
Identity verified at home stops working once it crosses a border. What is left is notarisation, apostille, translation and post.
eIDAS 2.0 · EUDI ARF · HAIP 1.0 FINAL
Every transaction an agent starts leaves an accountable party behind it. An API key cannot answer that question.
An API key only says what made the call. Keys are copied and delegated, and nothing anywhere records who operates the agent.
Concept-level disclosure · patent application in progress
A use case is only worth reading if you can check what obliges it. Each of these rests on published law or on a published profile.
| Use case | Regulatory or standards basis |
|---|---|
| Reusable KYC | Act on Reporting and Using Specified Financial Transaction Information (customer due diligence) · KRPersonal Information Protection Act (collection minimisation) · KR |
| Stablecoin holder credentials | Act on Reporting and Using Specified Financial Transaction Information · KRVirtual Asset User Protection Act · KRMiCA · EU (where issuance is offshore) |
| Paperless lending | Framework Act on Electronic Documents and Transactions · KRCredit Information Use and Protection Act · KR |
| Reverse identity proofing | Special Act on Telecommunications-based Financial Fraud · KRElectronic Financial Transactions Act · KR |
| Verifier-as-a-Service | OID4VP 1.0 FINALHAIP 1.0 FINAL |
| Cross-border eIDAS 2.0 | eIDAS 2.0 — Regulation (EU) 2024/1183EUDI Wallet Architecture and Reference Framework |
| AI agent identity | EU AI Act — Regulation (EU) 2024/1689, operator identification and loggingAML frameworks — identifying the actual party to a transaction |
We name the statute or the profile, not the article. Article-level citations follow legal review. Korean statutes are given in their commonly used English titles.
Sequence diagrams for issuance, presentation, reusable KYC and reverse identity proofing are published with fixed colours and line weights per role, so the same symbols read the same way across use cases. They are currently labelled in Korean — see the Korean solutions page. English versions are available on request.
Tell us the flow you run today and we will start by mapping where a credential fits into it.