Plán IT Stacku EMI

Plán IT Stacku EMI: Hlavní účetní kniha, KYC, monitorování transakcí, správa případů, reporting, zpracování karet

V roce 2026 se technologický stack EMI hodnotí méně podle „hezkých funkcí“ a více podle toho, zda umí produkovat auditně průkazné důkazy: správné zůstatky, dohledatelné toky, řízený outsourcing, odolný provoz a opakovatelné reportování. Důvěryhodný stack je takový, který umí kdykoli prokázat: co se stalo, proč se to stalo, kdo to schválil a jak se to promítá do safeguarding (oddělení chráněných prostředků) a účetnictví.

Blueprint formují dvě regulační reality:

• DORA se uplatňuje od 17. ledna 2025 a zvyšuje základní očekávání na řízení ICT rizik, incident handling, testování odolnosti a dohled nad ICT třetími stranami. V roce 2026 řada dozorů bere „DORA-style“ ICT governance jako minimální standard.
• Očekávání EBA v oblasti ICT a bezpečnostních rizik dál ovlivňují hodnocení bezpečnosti PSP/EMI, řízení přístupů, change managementu a bezpečnostních praktik směrem ke klientům, nyní v DORA kontextu. Zároveň byly zrušeny pokyny PSD2 pro hlášení závažných incidentů, protože DORA přinesla harmonizované incident reporting. Incident readiness tedy musí být navržená do platformy už od prvního dne.

Níže je praktická referenční architektura, kterou můžeš použít pro návrh (nebo vysvětlení) EMI stacku vůči dohledu, bankovním partnerům a investorům.

Referenční architektura (co se na co napojuje)

Kanály (Channels)

• Webové / mobilní aplikace
• Admin back office
• Partnerské portály / API

Vrstva core processing (Core processing layer)

• Core ledger (systém záznamu, system of record)
  
• Orchestrace plateb (SEPA/Instant/SWIFT, lokální rails)
• FX engine (kurzy, spready, booking)
• Integrace card processing (issuer processor / programme manager)

Vrstva finančních kontrol (Financial control layer)

• Reconciliation engine (výpisy z rails, settlement soubory z karet, safeguarding účty)
• Monitoring safeguarding a segregace
• Napojení na hlavní knihu / účetnictví (GL bridge)

Vrstva rizika a compliance (Risk & compliance layer)

• KYC/KYB + screening (sankce/PEP/adverse media)
• Transaction monitoring (pravidla + scénáře + risk scoring)
• Case management + SAR workflow
• Audit logging + evidence vault (trezor důkazů)

Vrstva reportingu (Reporting layer)

• Regulatorní reporting (prudenční, incidenty, AML metriky dle potřeby)
• Management information (MI): KRI, fraud, spory (disputes), provozní KPI

Platformní vrstva (Platform layer)

• IAM (role, MFA), secrets, šifrování, správa klíčů
• Observability (logy/metriky/traces), SIEM
• Registr dodavatelů/outsourcingu + kontrolní mechanizmy (kritické služby)
• BCP/DR + testování odolnosti (DORA očekávání)

Licenční úhel pohledu CZ/EU: dohled (včetně ČNB) typicky hledá (1) jasný „single source of truth“ pro zůstatky a safeguarding a (2) outsourcing governance odpovídající realitě (kdo co provozuje, pod jakými kontrolami a jak vypadá exit). Pokud architektonický diagram a seznam dodavatelů vyprávějí jiné příběhy, spustí to zbytečné Q&A cykly.

Core ledger: „single source of truth“

Ledger není „databáze“. Je to autoritativní engine, který musí být kdykoli schopný odpovědět:

• Jaký je zůstatek zákazníka právě teď?
• Jaký je zůstatek firmy právě teď?
• Co je safeguarded, co čeká na vypořádání, co bylo stornováno, v disputu nebo blokováno?

Nepodmínitelné vlastnosti ledgeru

• Podvojné účetnictví (nebo ekvivalentní kontrolní model)
• Neměnný journal (append-only; opravy přes reversace)
• Idempotence (retry nesmí duplikovat hodnotu)
• Jasný stavový model: available / pending / reserved / blocked / chargeback / reversal
• Silný audit trail navázaný na uživatelské akce i systémové události (kdo co udělal, kdy a s jakou autorizací)

Typické integrace

• Funding/top-ups, payouts, kartové autorizace/clearing, FX konverze, poplatky, chargebacky/refundy
• Výstupy z reconciliace do účetnictví/GL a do monitoringu safeguarding

Poznámka z praxe (CZ): vyprávění o ledgeru musí sedět s money-flow diagramy, metodou safeguarding a kadencí reconciliace. V balíčku příloh pro ČNB je ledger „engine pravdy“, na který se musí všechny ostatní tvrzení dopočítat.

KYC/KYB stack: onboarding, screening a lifecycle refresh

Ber KYC jako životní cyklus, ne jednorázovou bránu:

• Sběr identity (doklad + liveness, kde se používá)
• Screening sankcí/PEP
• Risk scoring (typ klienta, země, produkt, kanál)
• Průběžný monitoring & refresh (periodické review, trigger eventy)
• Offboarding (uzavření, redemption, retention)

Design rozhodnutí, která fakt rozhodují

• Vlastnictví dat: core identity atributy ukládej ve své doméně; odpovědi dodavatelů drž jako důkazní artefakty
• Řízení workflow: risk-based cesty (standard vs EDD), schvalování, segregace rolí
• Evidence vault: co uchováváš, retenční pravidla, přístupy, ochrana proti manipulaci (napojení na outsourcing a ICT controls očekávání)

EU/ČNB realita: dohled obvykle nemá rád model „KYC žije celý ve vendor portálu“. Chtějí důkaz, že vlastníš workflow, rozhodovací logiku a důkazy, zvlášť když onboarding a screening outsourcuješ.

Transaction monitoring: detekce není totéž co „alerty“

Důvěryhodný monitoring má tři vrstvy:

1. Pravidla/scénáře: thresholdy, velocity, structuring, neobvyklé koridory
2. Model rizika entity: customer risk + product risk + geo risk
3. Behavioural baselining: volitelné, ale ve velkém měřítku silné

Co do monitoringu napojit (minimum)

• Události z ledgeru (kredity/debity, interní převody)
• Události payout rails (odesláno/vráceno/odmítnuto)
• Kartové události (auth, reversals, clearing, chargebacky)
• FX události (konverze, refundy)
• KYC události (změny rizika, EDD flagy)

Požadavky na výstup

• Vysvětlitelná logika alertu (proč se spustil, která data to způsobila)
• Decision trail (vyšetřit → uzavřít/eskalovat; kdo schválil)
• Prolinkovatelné důkazy (snapshoty, immutable reference, přílohy)

To podporuje širší očekávání „auditability“ v governance a ICT/security: monitoring musí být prokazatelně řízený, vysvětlitelný a opakovatelný, ne black box.

Case management: „řídicí místnost“ pro AML, fraud a spory

Vyhni se klasickému failu: alerty v jednom nástroji, investigace v Excelu, SAR drafty v e-mailu. To se pod dohledem brání mizerně.

Mature case tool podporuje:

• Queueing + SLA (podle rizika / závažnosti)
• Poznámky vyšetřovatelů + přílohy + zamykání důkazů
• Taxonomii rozhodnutí (false positive / closed / filed / exited)
• SAR workflow a schvalování
• Reporting (alert-to-case konverze, cycle time, backlog)

V DORA éře by case platforma měla být i odolná a obnovitelná: backupy, audit logy, governance přístupů a řízené restore procesy.

Licenční úhel pohledu CZ: když popisuješ AML/fraud/dispute operace pro ČNB, ukaž opakovatelné kontrolní procesy, ne jen nástroje. To znamená měřitelné SLA, tamper-evident logy, role-based access a jasnou segregaci rolí v back office.

Reporting: stav „regulatory + MI“ na stejném engine pravdy

Dvě třídy reportingu

• Regulatorní reporting: prudenční a další povinná hlášení dle rozsahu a jurisdikce
  
• Management reporting (MI):
  
  • zůstatky a safeguarding status
  • fraud/disputes KPI
  • AML KPI (alerty, cases, SAR rozhodnutí)
  • provozní incidenty a uptime metriky

Incident reporting: navrhni to do platformy

Protože DORA zavedla harmonizované incident reporting od 17. ledna 2025 a PSD2 pokyny pro major incident reporting byly zrušeny, platforma musí umět incidenty konzistentně klasifikovat, evidovat a reportovat. Není to „jen politika“. Potřebuješ logy, timeline, důkazy dopadu a opakovatelné reporting workflow.

Praktická poznámka pro CZ/EU: i když nebudeš podávat každý možný report od Day 1, platforma musí prokázat, že umíš vytvořit požadované výstupy z řízených dat, s audit trail a důkazními přílohami.

Card processing: drž kartovou doménu čistou

Kartové programy přinášejí víc „truth systémů“:

• Autorizační stream (téměř real-time)
• Clearing & settlement soubory (batch)
• Chargebacky/disputes (dlouhý tail)

Tip blueprintu: ber karty jako event source, který účtuješ do ledgeru přes řízené mapování:

• auth → rezervace prostředků (pending)
• clearing → finální zaúčtování
• reversal → uvolnění rezervy
• chargeback → dispute stav + účetní zápisy

Zároveň musíš umět reconciliovat:

• processor výpisy ↔ ledger ↔ safeguarding účty ↔ GL

CZ/EU realita: kartové programy jsou plné výjimek (chargebacky, partial reversals, offline clearing). Dohled méně řeší „rychlé karty“ a více to, zda umíš reconciliovat, dokládat rozhodnutí a zabránit balance driftu v edge casích.

Integrační vzory, které snižují provozní riziko

Doporučené patterny

• Event bus pro posting a monitoring (ledger, karty, payouty)
• Outbox pattern pro konzistentní publikaci eventů z ledgeru
• Silný API gateway + IAM a rate limiting
• Centralizované logování + SIEM (retence vhodná pro vyšetřování)
• Verzionované konfigurace pro monitoring rules (change control)

Outsourcing control je součást architektury

EBA očekávání k outsourcingu tlačí instituce k posouzení, zda jsou outsourcované služby „critical or important“, a k jejich řízení (registry, dohled, auditní práva, exit). V praxi by každý klíčový vendor (KYC, monitoring, processor, cloud) měl být namapovaný na:

• kritičnost
• RTO/RPO
• auditní práva
• subdodavatelé
• exit plán

Build vs buy: co kupovat a co vlastnit

Obvykle kupovat

• KYC ověření dokladů (ale workflow a evidence model vlastni ty)
• screening sankcí/PEP
• card processing stack (processor/programme manager)
• case management (pokud nejsi v masivním scale)

Obvykle vlastnit

• ledger logiku (i při vendor core musíš vlastnit posting pravidla a kontroly)
• rozhodnutí v risk modelu a monitoring governance
• reconciliaci a safeguarding kontrolní logiku (odpovědnost je tvoje)

Implementační roadmapa (praktické pořadí)

1. Ledger + money flows (wallet, fees, posting pravidla)
2. Orchestrace rails + reconciliace (aby šlo zavřít účetní období a prokázat safeguarding)
3. KYC + screening + risk scoring
4. Transaction monitoring + case management
5. Karty (auth/clearing/chargebacky + reconciliace)
6. Reporting + incident readiness (DORA-aligned provozní vyspělost)

Rychlý checklist: co dělá EMI stack „důvěryhodným“ v roce 2026

• Ledger je neměnný, podvojný a audit-ready
• Všechny externí rails se denně reconciliují (s exception handling)
• Monitoring je napojený na reálné ledger + rail + card eventy
• Cases jsou end-to-end (alerty → rozhodnutí → důkazy)
• Reporting používá jeden řízený datový model
• Outsourcing registr existuje a odpovídá realitě
• Incident capture a reporting capability je vestavěná (DORA éra)

Pomáháme EMI s IT architekturou

Pokud připravuješ žádost o licenci EMI v České republice (ČNB), AMS ti může pomoct vybudovat regulator-ready IT architekturu a narativ stacku, který sedí s českým annex-driven přístupem k podání. Pokrýváme core ledger a money flows, safeguarding/reconciliace, outsourcing registr a kritičnost dodavatelů, governance přístupů a DORA-era incident readiness.

Podporujeme také finanční plány a 3leté finanční modely pro české EMI žádosti. Hlídáme, aby zůstatky, logika vlastních zdrojů, předpoklady likvidity, safeguarding operace a IT/outsourcing popisy byly konzistentní, takže podání je obhajitelné během Q&A s ČNB.

ZÍSKEJTE ČNB-READY GAP CHECK A JASNÝ SEZNAM OPRAV

SPUSTIT EMI PRE-CHECK

OBJEDNAT

FAQ: PLÁN IT STACKU EMI

Jakou dokumentaci ČNB typicky očekává k doložení IT stacku EMI při licencování?

Kromě architektonických diagramů dohled obvykle chce „důkazní artefakty“, že stack umíš v praxi řídit. Užitečné dokumenty bývají vendor due diligence balíček (role, SLA, subdodavatelé), matice oprávnění pro back office přístupy, ukázkové reconciliation reporty, incident response runbooky a důkazy o plánech testování DR/BCP. Tyto materiály pomáhají prokázat provozní připravenost pro žádost o licenci EMI v ČR.

Jak může EMI snížit licenční riziko při využití cloudu a fintech vendorů v Evropě?

Nejlepší je brát vendor governance jako součást návrhu systému, ne jako právní dodatek na poslední chvíli. To znamená definovat kritičnost dodavatelů, auditní práva, monitoring, cíle RTO/RPO, transparentnost subdodavatelů a realistický exit plán. Pro EU EMI, zvlášť při podání k ČNB, strukturovaný dohled nad třetími stranami výrazně snižuje follow-up otázky k outsourcingu a řízení ICT rizik.

Jaké je nejčastější „skryté selhání“ v EMI systémech, které způsobuje spory o zůstatky a rozpad reconciliace?

Častým kořenovým problémem je nekonzistentní mapování eventů mezi externími systémy (kartové procesory, payment rails, FX poskytovatelé) a interní posting logikou EMI. Drobné edge case situace, jako partial reversals, zpožděné settlement soubory, pozdní chargebacky nebo FX rozdíly u refundů, se mohou nasčítat do „balance driftu“. Robustní platforma tomu brání jasnými booking pravidly, idempotencí a exception handlingem, plus denní reconciliací, která vytváří dohledatelné důkazy.

Jak vybrat správný case management systém pro AML a fraud, aniž bys zbytečně overbuildoval?

Praktický přístup je začít workflow a důkazními požadavky, ne „feature listem“. Systém má umět audit-grade case notes, přílohy, schvalování, konfigurovatelné outcomes a reporting, který ukazuje, jak se alerty mění v cases a rozhodnutí. Pro EMI licencování v Evropě je navíc plus, pokud nástroj umí exportovat kompletní evidence bundle pro audit nebo dohled, bez závislosti na Excelu a e-mailových řetězcích.

Jak má EMI prokázat DORA-ready incident management v IT stacku (a proč je to pro licencování důležité)?

Dohled čím dál víc čeká, že incident readiness bude „vestavěná do platformy“, ne řešená ručně. V praxi to znamená konzistentní klasifikaci incidentů, evidence capture (logy, timeline, zasažené služby, dopad na uživatele), jasné vlastnictví a eskalace a opakovatelné reporting výstupy. Dobrý přístup je propojit observability (logy/metriky/traces) a SIEM s incident workflow, které zachovává neměnné důkazy a umí na vyžádání vyprodukovat audit-ready reporty, takže obhájíš operační odolnost při licenčním posuzování i průběžném dohledu.