EMI IT Stack Blueprint

EMI IT Stack Blueprint: Core Ledger, KYC, Transaction Monitoring, Case Management, Reporting, Card Processing

In 2026, an EMI’s tech stack is judged less by “nice features” and more by whether it produces audit-ready evidence: correct balances, traceable flows, controlled outsourcing, resilient operations, and repeatable reporting. A credible stack is one that can prove—at any time—what happened, why it happened, who approved it, and how it reconciles to safeguarding and accounting.

Two regulatory realities shape the blueprint:

1. DORA has applied since 17 January 2025, raising baseline expectations for ICT risk management, incident handling, resilience testing, and third-party ICT oversight. By 2026, many supervisors treat “DORA-style” ICT governance as a minimum bar.
2. EBA ICT & security risk management expectations continue to influence how PSP/EMI security, access control, change management, and customer-facing security practices are assessed—now in a DORA-era context. Also, PSD2 major incident reporting guidelines were repealed because DORA introduced harmonised incident reporting, so incident readiness must be designed into the platform from day one.

Below is a practical reference architecture you can use to design (or explain) your EMI stack to supervisors, banking partners, and investors.

Reference architecture (what connects to what)

Channels

• Web / Mobile apps
• Admin back office
• Partner portals / APIs

Core processing layer

• Core ledger (system of record)
• Payments orchestration (SEPA/Instant/SWIFT, local rails)
• FX engine (rates, spreads, booking)
• Card processing integration (issuer processor / programme manager)

Financial control layer

• Reconciliation engine (rail statements, card settlement files, safeguarding accounts)
• Safeguarding and segregation monitoring
• General ledger / accounting bridge

Risk & compliance layer

• KYC/KYB + screening (sanctions/PEP/adverse media)
• Transaction monitoring (rules + scenarios + risk scoring)
• Case management + SAR workflow
• Audit logging + evidence vault

Reporting layer

• Regulatory reporting (prudential, incidents, AML metrics as needed)
• Management information (MI): KRIs, fraud, disputes, operational KPIs

Platform layer

• IAM (roles, MFA), secrets, encryption, key management
• Observability (logs/metrics/traces), SIEM
• Vendor/outsourcing register + controls (critical services)
• BCP/DR + resilience testing (DORA expectations)

Czech/EU licensing angle: supervisors (including ČNB) typically look for (1) a clear “single source of truth” for balances and safeguarding, and (2) outsourcing governance that matches reality (who runs what, under which controls, and how you exit). If your architecture diagram and your vendor list tell different stories, it triggers unnecessary Q&A cycles.

Core ledger: the “single source of truth”

Your ledger is not “a database.” It is the authoritative engine that must answer, at any point in time:

• What is the customer’s balance right now?
• What is the firm’s balance right now?
• What is safeguarded, pending settlement, reversed, disputed, or blocked?

Non-negotiable ledger characteristics

• Double-entry accounting (or an equivalent controls model)
• Immutable journal (append-only entries; corrections via reversals)
• Idempotency (retries don’t duplicate value)
• Clear state model: available / pending / reserved / blocked / chargeback / reversal
• Strong audit trail tied to user actions + system events (who did what, when, and under which authorisation)

Typical integrations

• Funding/top-ups, payouts, card authorisations/clearing, FX conversions, fees, chargebacks/refunds
• Reconciliation outputs feeding accounting/GL and safeguarding monitoring

Czech practice note: your ledger narrative must align with your money-flow diagrams, safeguarding method, and reconciliation cadence. In a ČNB annex package, the ledger is the “truth engine” that all other claims must reconcile to.

KYC/KYB stack: onboarding, screening, and lifecycle refresh

Treat KYC as a lifecycle, not a one-time gate:

• Identity capture (document + liveness where used)
• Sanctions/PEP screening
• Risk scoring (customer type, country, product, channel)
• Ongoing monitoring & refresh (periodic reviews, trigger events)
• Offboarding (closures, redemption, retention)

Design decisions that matter

• Data ownership: store core identity attributes in your domain; keep vendor responses as evidence
• Workflow control: risk-based paths (standard vs EDD), approvals, and segregation of duties
• Evidence vault: what you retain, retention rules, access controls, and tamper-evidence (tie to outsourcing and ICT controls expectations)

EU/ČNB realism: supervisors generally do not like “KYC lives entirely inside a vendor portal.” They want proof that you own the workflow, the decision logic, and the evidence—especially if onboarding and screening are outsourced.

Transaction monitoring: detection is not the same as “alerts”

A credible monitoring capability has three layers:

• Rules/scenarios: thresholds, velocity, structuring, unusual corridor
• Entity risk model: customer risk + product risk + geo risk
• Behavioural baselining: optional, but powerful at scale

What to wire into monitoring (minimum)

• Ledger events (credits/debits, internal transfers)
• Payout rails events (sent/returned/rejected)
• Card events (auth, reversals, clearing, chargebacks)
• FX events (conversion, refunds)
• KYC events (risk changes, EDD flags)

Output requirements

• Explainable alert logic (why it triggered, what data points caused it)
• Decision trail (investigate → close/escalate; who approved)
• Linkable evidence (supporting snapshots, immutable references, attachments)

This supports the broader “auditability” expectation embedded in governance and ICT/security expectations: monitoring must be demonstrably controlled, explainable, and repeatable—not a black box.

Case management: the “control room” for AML, fraud, disputes

Avoid the common failure mode: alerts live in one tool, investigations in spreadsheets, SAR drafts in email. That is hard to defend under supervision.

A mature case tool supports:

• Queueing + SLAs (by risk / severity)
• Investigator notes + attachments + evidence locking
• Decision taxonomy (false positive / closed / filed / exited)
• SAR workflow and approvals
• Reporting (alert-to-case conversion, cycle time, backlogs)

With DORA-era expectations, the case platform should also be resilient and recoverable: backup, audit logs, access governance, and controlled restoration processes.

Czech licensing angle: when you describe AML/fraud/dispute operations to ČNB, show repeatable control processes—not just tools. That means measurable SLAs, tamper-evident logs, role-based access, and clear segregation of duties in the back office.

Reporting: build “regulatory + MI” from the same truth

Two reporting classes

Regulatory reporting: prudential and other required submissions depending on scope and jurisdiction
Management reporting (MI):

• balances and safeguarding status
• fraud/disputes KPIs
• AML KPIs (alerts, cases, SAR decisions)
• operational incidents and uptime metrics

Incident reporting: design it into your platform

Because DORA introduced harmonised incident reporting from 17 January 2025 and PSD2 major incident reporting guidance was repealed, your platform should be able to classify, evidence, and report incidents consistently. This is not a “policy-only” requirement: you need logs, timelines, impact evidence, and repeatable reporting workflows.

Practical note for CZ/EU: even if you do not file every possible report on day one, the platform should prove you can produce required outputs from controlled data, with an audit trail and evidence attachments.

Card processing: keep the card domain clean

Card programs introduce multiple “truth systems”:

• Authorisation stream (near real-time)
• Clearing & settlement files (batch)
• Chargebacks/disputes (long tail)

Blueprint tip: treat cards as an event source that books into your ledger through a controlled mapping:

• auth → reserve funds (pending)
• clearing → finalise posting
• reversal → release reserve
• chargeback → create dispute state and accounting entries

Also ensure you can reconcile:

• processor statements ↔ ledger ↔ safeguarding accounts ↔ GL

Czech/EU reality: card programmes are exception-heavy (chargebacks, partial reversals, offline clearing). Supervisors care less about “fast cards” and more about whether you can reconcile, evidence decisions, and prevent balance drift under edge cases.

Integration patterns that reduce operational risk

Recommended patterns

• Event bus for posting and monitoring (ledger events, card events, payout events)
• Outbox pattern for consistent event publishing from the ledger
• Strong API gateway + IAM and rate limits
• Centralised logging + SIEM (investigation-grade retention)
• Versioned configs for monitoring rules (change control)

Outsourcing control is part of the architecture

EBA outsourcing expectations push institutions to assess whether outsourced services are “critical or important” and manage them accordingly (registers, oversight, audit rights, exits). In practice, every key vendor (KYC, monitoring, processor, cloud) should be mapped to:

• criticality
• RTO/RPO
• audit rights
• subcontractors
• exit plan

Build-vs-buy: what to buy, what to own

Usually buy

• KYC document verification (but own the workflow and evidence model)
• sanctions/PEP screening
• card processing stack (processor/programme manager)
• case management (unless you’re at huge scale)

Usually own

• ledger logic (even if you use a vendor core, you own posting rules and controls)
• risk model decisions and monitoring governance
• reconciliation and safeguarding control logic (your accountability)

Implementation roadmap (practical order)

1. Ledger + money flows (wallet, fees, posting rules)
2. Rails orchestration + reconciliation (so you can close books and prove safeguarding)
3. KYC + screening + risk scoring
4. Transaction monitoring + case management
5. Cards (auth/clearing/chargebacks + reconciliation)
6. Reporting + incident readiness (DORA-aligned operational maturity)

Quick checklist: what makes an EMI stack “credible” in 2026

• Ledger is immutable, double-entry, and audit-ready
• All external rails are reconciled daily (with exception handling)
• Monitoring connects to real ledger + rail + card events
• Cases are end-to-end (alerts → decisions → evidence)
• Reporting uses one controlled data model
• Outsourcing register exists and matches reality
• Incident capture and reporting capability is built-in (DORA era)

We help EMIs with IT architecture

If you are preparing an EMI licence application in the Czech Republic (ČNB), AMS can help you build a regulator-ready IT architecture and stack narrative that aligns with the Czech annex-driven submission approach—covering core ledger and money flows, safeguarding/reconciliations, outsourcing register and vendor criticality, access governance, and DORA-era incident readiness.

We also support financial plans and 3-year EMI financial models for Czech applications, ensuring your balances, own-funds logic, liquidity assumptions, safeguarding operations, and IT/outsourcing descriptions stay consistent—so the submission is defendable during ČNB Q&A.

GET A ČNB-READY GAP CHECK AND A CLEAR FIX LIST

 

START EMI PRE-CHECK

ORDER

FAQ: EMI IT STACK BLUEPRINT

What documentation does ČNB typically expect to support an EMI’s IT stack during licensing?

Beyond architecture diagrams, supervisors usually look for “proof artefacts” that show the stack can be controlled in practice. Useful supporting documents include a vendor due diligence pack (roles, SLAs, subcontractors), a permissions matrix for back office access, sample reconciliation reports, incident response runbooks, and evidence of DR/BCP testing plans. These materials help demonstrate operational readiness for an EMI licence application in the Czech Republic.

How can an EMI reduce licensing risk when using cloud services and third-party fintech vendors in Europe?

The best way is to treat vendor governance as part of the system design, not a legal afterthought. That means defining vendor criticality, audit rights, monitoring, RTO/RPO targets, subcontractor transparency, and a realistic exit plan. For EU EMIs—especially those applying under ČNB—showing structured third-party oversight can significantly reduce follow-up questions about outsourcing and ICT risk management.

What is the most common “hidden failure” in EMI systems that causes balance disputes and reconciliation breaks?

A frequent root cause is inconsistent event mapping between external systems (card processors, payment rails, FX providers) and the EMI’s internal posting logic. Small edge cases—partial reversals, delayed settlement files, late chargebacks, or refund FX differences—can accumulate into “balance drift.” A robust EMI platform prevents this by enforcing clear booking rules, idempotency, and exception handling, with daily reconciliation that produces traceable evidence.

How do you choose the right case management system for AML and fraud without overbuilding?

A practical selection approach is to start with workflows and evidence requirements rather than features. The system should support audit-grade case notes, attachments, approvals, configurable decision outcomes, and reporting that shows how alerts convert into cases and decisions. For EMI licensing in Europe, it’s also valuable if the tool can export complete evidence bundles for audits and supervisory requests—without relying on spreadsheets or manual email trails.

How should an EMI demonstrate DORA-ready incident management in its IT stack (and why does it matter for licensing)?

Supervisors increasingly expect incident readiness to be “built into the platform,” not handled manually. In practice, that means your stack should support consistent incident classification, evidence capture (logs, timelines, affected services, user impact), clear ownership and escalation paths, and repeatable reporting outputs. A good approach is to link observability (logs/metrics/traces) and SIEM to an incident workflow that preserves immutable evidence and can produce audit-ready reports on demand—so you can defend operational resilience during licensing reviews and ongoing supervision.