DEV Community: Taisia

Most bank onboarding flows are still built around the assumption that identity data lives with the user.

Taisia — Wed, 03 Jun 2026 19:34:22 +0000

It doesn't. It lives in government systems, company registries, and identity providers — and the onboarding architecture should reflect that.

This post breaks down what a modern KYC onboarding flow looks like when it's built around existing identity infrastructure instead of manual data collection. I'll walk through the technical components: the identity redirect, registry pull, UBO graph, AML hook, and risk scoring inputs.

The core architectural shift

Traditional KYC onboarding is a data collection pipeline:

User inputs data → Bank stores → Verification service checks → AML runs → Decision

The problem: the bank is treating the user as the data source. They're not — they're an unreliable intermediary between the bank and verified government records.

Modern onboarding treats identity providers and registries as the data source, and the user as the consent layer:

User consents → Gov identity provider returns verified data →
Registry returns entity structure → AML runs on verified graph → Decision

Step 1: The identity redirect (OAuth-style)

The flow starts when the user selects digital ID at the onboarding entry point.

The bank initiates an OAuth 2.0 / OpenID Connect authorization request to the government identity provider (e.g. Estonia's X-Road / Smart-ID, Moldova's MPASS). The user authenticates at the provider level — the bank never sees credentials.

On successful authentication, the identity provider returns a signed assertion:

json { "sub": "EE38512120123456", "given_name": "Anna", "family_name": "Mägi", "birthdate": "1985-12-12", "document_type": "ID_CARD", "document_number": "AA1234567", "verified_at": "2026-05-20T10:32:00Z", "assurance_level": "high" }

The assurance_level: high signals that identity was verified by a government-issued credential at LoA3 (Level of Assurance 3), satisfying strong KYC requirements under AMLD5/6 in the EU context.

No document upload. No OCR. No liveness check needed if the IdP already performed biometric verification.

Step 2: Registry pull for business accounts

For corporate onboarding, the bank queries the national company registry API using the verified identity as the lookup key.

GET /registry/entities?beneficial_owner=NATIONAL_ID&status=active

The registry returns all entities where the authenticated individual appears as a director, shareholder, or beneficial owner:

{ "entities": [ { "registration_number": "12345678", "legal_name": "Example OÜ", "legal_form": "private_limited", "registered_address": "Tallinn, Estonia", "industry_code": "6419", "directors": ["..."], "shareholders": [ { "name": "Anna Mägi", "national_id": "EE38512120123456", "ownership_percentage": 75.0, "ownership_type": "direct" }, { "name": "Holding OÜ", "registration_number": "87654321", "ownership_percentage": 25.0, "ownership_type": "indirect" } ] } ] }

If a shareholder is itself a legal entity, the bank resolves ownership recursively — calling the registry again for that entity’s shareholders — until every chain terminates at a natural person with ≥25% ownership (the standard UBO threshold under AMLD).

Step 3: Building the UBO ownership graph

The result of the recursive registry resolution is an ownership graph. For AML screening, this graph needs to be flattened into a list of UBOs with calculated effective ownership.

`def resolve_ubos(entity_id, ownership_pct, visited=set()):
if entity_id in visited:
return [] # break circular ownership loops
visited.add(entity_id)

shareholders = registry.get_shareholders(entity_id)
ubos = []

for s in shareholders:
    effective_pct = ownership_pct * (s.ownership_percentage / 100)
    if s.is_natural_person:
        ubos.append(UBO(person=s, effective_ownership=effective_pct))
    else:
        ubos.extend(resolve_ubos(s.registration_number, effective_pct, visited))

return ubos`

This gives you a clean list of natural persons with their effective ownership percentage — ready for AML screening.

Step 4: AML screening hooks into the UBO graph

Each UBO is submitted to the bank’s sanctions and PEP screening provider:

{ "subjects": [ { "name": "Anna Mägi", "dob": "1985-12-12", "nationality": "EE", "role": "UBO", "effective_ownership": 75.0 } ], "screening_types": ["sanctions", "pep", "adverse_media"], "match_threshold": 85 }

Screening runs against OFAC, EU consolidated list, UN sanctions, and PEP databases. Results return with match confidence scores. Hits above the threshold trigger a manual review queue rather than auto-approval.

Because UBO data came from a verified registry rather than self-reported fields, false positive rates drop significantly — names and dates of birth are verified, not user-entered.

Step 5: Risk scoring inputs

AML risk scoring combines verified identity and structural data with behavioral signals:

Signal	Source	Notes
Industry code	Company registry	NACE code maps to AML risk category
Geography	Registry + IP	Incorporation country, operating countries
Expected transaction volume	User-provided	Only manual input in the flow
Typical recipient types	User-provided	Cross-border, consumer, B2B
Device fingerprint	Client-side SDK	Fraud signal, not AML directly
Open banking behavior	PSD2 / consent	Transaction pattern from existing accounts

The risk score output determines initial access tier — which transaction limits apply, whether enhanced due diligence is triggered, and whether any services are conditionally available.

What the user actually enters manually

With this architecture, the only data a user provides manually is what genuinely doesn’t exist in any system yet:

• Expected monthly transaction volume
• Typical payment recipients (individuals, businesses, cross-border)
• Purpose of the account

Everything else — identity, corporate structure, UBO chain, verified document data — comes from authoritative sources via API.

UX layer: the progress bar as a trust signal

For flows with multiple steps (identity verification → entity selection → risk questions → decision), always surface a step indicator to the user.

This is not cosmetic. Abandonment in multi-step onboarding correlates strongly with uncertainty about remaining duration, not with actual step count. A user who knows they’re on step 3 of 5 behaves differently from a user who doesn’t know when it ends.

For compliance flows specifically, where you legally can’t skip steps, the UX contract with the user depends on setting accurate expectations.

Infrastructure that already exists

• Estonia: X-Road + Smart-ID + e-Business Register — full stack connected
• EU eIDAS 2.0: European Digital Identity Wallet — framework being rolled out across member states
• Moldova: MPASS identity portal + State Registration Chamber API — components exist, not yet connected into a unified onboarding product
• UK: GOV.UK One Login — identity layer live, banking integration limited

The technical building blocks are mostly there. The gap is product integration — banks treating these APIs as onboarding infrastructure rather than optional add-ons.

I build payment and compliance systems inside a regulated EMI, working across AML tooling, sanctions screening, and KYC architecture. Writing here about what compliance engineering actually looks like from the inside.

Originally discussed on LinkedIn

fintech #KYC #AML #digitalidentity #bankingUX #compliancetech #fintechEurope #onboarding #regulatorytech #productdesign

How Compliance Is Designed Into Stablecoins

Taisia — Tue, 20 Jan 2026 08:12:40 +0000

Stablecoins fail because of missing design decisions.

This video explains the product and compliance layer required before any stablecoin can operate:
• Mint & burn mechanics
• Identity verification and transaction monitoring
• Secure custody models
• Smart contract control mechanisms

If you’re researching:
“how stablecoins work in practice”
“stablecoin compliance requirements”
“mint and burn explained”

— this video answers those questions clearly.
https://youtube.com/shorts/BQNjwwYW1vA?si=qmzqpXl9wyn-7WQQ

fintech #stablecoins #payments #regulation #infrastructure

You can’t “move fast and break things” with money.

Taisia — Mon, 05 Jan 2026 11:52:20 +0000

Stablecoins aren’t just software — they’re regulated financial products.
Watch now

This video covers Phase 1: Regulation & Partnerships, including:

Regulatory engagement
Banking and safeguarding accounts
Custody models
Audit and proof-of-reserves

This is where legitimacy is built.

#fintech #stablecoins #payments #regulation #infrastructure

You can’t “move fast and break things” with money.

Taisia — Mon, 05 Jan 2026 11:52:20 +0000

Stablecoins aren’t just software — they’re regulated financial products.
Watch now

This video covers Phase 1: Regulation & Partnerships, including:

Regulatory engagement
Banking and safeguarding accounts
Custody models
Audit and proof-of-reserves

This is where legitimacy is built.

#fintech #stablecoins #payments #regulation #infrastructure

Before writing a single line of code, stablecoin teams need alignment.

Taisia — Wed, 24 Dec 2025 08:43:43 +0000

This video covers Phase 0 — Strategy & Framing:

Target users
Currency choice
Regulatory jurisdiction

It’s the foundation every successful stablecoin project needs.

https://www.linkedin.com/posts/taisia-bobrova_stablecoins-fintech-payments-activity-7409476676314759168-x6AU?utm_source=share&utm_medium=member_desktop&rcm=ACoAAC6zf7UBuTeCFIyoc2JIZBOlHxpCVUzOIPw

Stablecoins are moving from hype to infrastructure.

Taisia — Mon, 22 Dec 2025 05:03:11 +0000

Watch now

This video introduces a practical series where I break down how EMIs and fintechs actually implement stablecoins — covering regulation, custody, mint/burn flows, and operations.

If you’re building in payments or fintech, this series is for you.

💬 Comment “checklist” for the full implementation project plan.

🪙 Building a Stablecoin Product — From Strategy to Launch

Taisia — Fri, 14 Nov 2025 05:55:00 +0000

Everyone talks about stablecoins as technology. But building one that's regulator-ready from day one? That's product work at the intersection of finance, compliance, and engineering.

Over the last months, I've been designing and documenting a complete Stablecoin Implementation Framework - turning regulation and operational complexity into a repeatable product process.

Here's the structure I follow 👇

Phase 1 - 🎯 Define
Clarify why the product should exist.

Decide the use cases (payments, merchant settlement, remittances).
Choose the currency pair (GBP, EUR) and legal domicile.
Map the FCA permissions required - issuing, safeguarding, custody. Before a single line of code, the product must already fit within a regulatory perimeter.

Phase 2 - 🧠 Ideate
Translate compliance into experience.

Design flows for mint → send → redeem that feel as simple as fintech, not as heavy as finance.
Model token economics, pricing, and limits. Every concept must make sense to both the user and the regulator.

Phase 3 - ⚙️ Prototype
Prove the logic before touching mainnet.

Simulate mint/burn orchestration off-chain.
Run early KYC/KYB and reconciliation tests.
Make sure every transaction is verifiable, reversible, and transparent. If it breaks here, it's far cheaper than breaking under supervision.

Phase 4 - 🏗️Build
Turn architecture into infrastructure.

Develop smart contracts, mint/burn engine, custody integrations, and treasury dashboards.
Embed AML/KYT tools, automate reporting, and connect ISO 20022 banking rails. The output is not just a system - it's an auditable, controlled environment regulators can trust.

Phase 5 - 👨‍🚀 Pilot
Validate under real-world pressure.

Run a closed pilot with selected partners.
Stress-test liquidity, compliance workflows, and incident playbooks.
Document everything - regulators respect evidence more than ambition.

Phase 6 - 🚀 Launch & Operate
Go live - but stay governed.

Maintain proof-of-reserves, merchant onboarding, and 24/7 monitoring.
Audit monthly, review quarterly, evolve continuously. A stablecoin isn't "done"; it's a living financial product with ongoing accountability.

👉 Building a compliant stablecoin is not about blockchain first. It's about alignment - between product, treasury, compliance, and regulation. When those move in sync, trust becomes your product advantage.

🎥 Over the next few weeks, I'll be releasing short videos breaking down each phase - practical insights, tool stacks, and what to expect at every stage.

💬 I'd love to hear which part you're closest to: Are you handling product, compliance, finance, or tech?

Comment below 👇 - and follow to get notified when the first short drops.

#fintech #stablecoin #productmanagement #regtech #digitalcurrency #fintechstrategy #financialinnovation

Stablecoins: from hype to real payments infrastructure

Taisia — Sun, 09 Nov 2025 16:34:02 +0000

Crypto swings 10% a day.
Stablecoins? Always $1.

A stablecoin is a digital token pegged 1:1 to a stable asset (USD, EUR, GBP).
Think: crypto — but without the volatility.

✅ Fiat-backed (USDC, USDT, PYUSD) → backed by cash/T-bills in a bank.
⚙️ Algorithmic/crypto-backed (DAI) → collateralized by crypto.

For banks, EMIs & PSPs, only fiat-backed matters: regulated, redeemable, and bank-collateralized.

⸻

Where they’re used today

💸 Payments & settlement — faster cross-border flows
🏦 Treasury — instant liquidity vs. bank deposits
🔗 On/off ramps — bridging fiat ↔ crypto

Visa already settles some payments in USDC. PayPal issues PYUSD via Paxos.

⸻

Regulation catches up (2024–2025):

🇪🇺 MiCA → EUR stablecoins: 1:1 reserves, redemption rights
🇬🇧 FSMA 2023 → FCA & BoE oversight
🇺🇸 Still fragmented, but momentum building (Clarity for Payment Stablecoins Act)

👉 If it acts like money → regulate it like like money.

⸻

Opportunities for EMIs & banks
🚀 Wallets & merchant settlement in stablecoins
⚡ Faster cross-border treasury flows
🛡️ Compliance through KYT + blockchain analytics

⸻

Why it matters now
• Stablecoins already settle more value on-chain than Visa + Mastercard combined.
• USDT + USDC > $130B market cap.
• Regulation = adoption without the grey zone.

Stablecoins aren’t “future crypto hype.”
They’re today’s upgrade to global money movement. 💬

Stablecoins #Fintech #Payments #Blockchain #Crypto #DigitalFinance #Innovation #EMI #BankingTransformation