k0nsult.cloud / ai-truth / ipIII / banking-demo / en
Banking security demo
A scenario page for a bank's CISO, SOC, compliance and audit functions. It shows how the K0NSULT system turns a single report into an auditable evidence chain and ready reports for the authorities — without "taking anyone's word for it". The whole scenario below is marked SIMULATION: it demonstrates the flow, not a real breach.
What the bank gets: proof, not a declaration.
Every incident has a chain: report → evidence (hash + timestamp) → status → classification → risk → playbook → action → validation → report. The financial supervisor's auditor sees a complete, non-repudiable trail. The SOC gets a ready playbook. The DPO gets a ready filing template. This shortens response time and closes the audit gap.
1. Executive summary — what the system gives the bank
Incident mapping
One coherent taxonomy for classic cyber, AI/agentic incidents, legal breaches and continuity. Threat Map + a table for the board.
Auditable evidence chain
Every claim has an evidence status and a chained hash. Material ready for internal audit, the supervisor and a court.
Ready reports for authorities
Templates for NIS2 (24h/72h/final), GDPR art. 33/34, AI Act art. 73 — populated from the evidence layer.
Response playbooks
Defined steps for phishing, ransomware, DDoS, data leak, supply chain and AI threats. Shorter MTTR.
AI tool firewall
AI agents in the bank under control: DID, scoring, tool allowlist, human approval for payment actions, kill switch.
Human-in-the-loop register
A non-repudiable decision log — who, when, on what basis. The foundation of accountability before the regulator.
2. Mapping to banking-sector requirements
| Regime | Requirement | System response |
|---|
| DORA (Reg. 2022/2554) | ICT risk management, classification and reporting of major ICT incidents, resilience testing (TLPT). | Classification Engine + P0–P3 thresholds, evidence chain, incident-report templates, continuity/DR module. |
| Supervisory IT / security guidance | Governance of IT and the security of the ICT environment, audit trail. | Incident register, action trace, decision register, evidentiary export for audit. |
| PSD2 — SCA | Strong customer authentication, fraud detection and handling. | Phishing/PhaaS playbook, LAW_ENFORCEMENT flag, linkage of fraud events to evidence. |
| NIS2 / national cybersecurity law | 24h/72h/final report to the CSIRT, risk-management measures. | NIS2 path with deadline clocks, flags NIS2_RELEVANT/CRITICAL_INFRA. |
| GDPR | Breach notification to the supervisory authority ≤72h (art. 33), notification of data subjects (art. 34). | DPO workflow with a 72h clock, art. 33/34 templates, GDPR_BREACH flag. |
| AI Act | Transparency (art. 50 from 2 Aug 2026), serious AI incidents (art. 73), high-risk scoring (Annex III). | Legal/Compliance Engine, AI_* flags, agent tool firewall, art. 73 report. |
FRAMEWORK/NORM The "requirement" column describes the publicly known text of sectoral regulation; it is not compliance advice for a specific bank. AI Act Annex III (credit scoring) — obligation deferred to 2 Dec 2027 (Digital Omnibus).
3. End-to-end demo scenario: phishing against a bank
SIMULATION: the incident INC-DEMO-7742 below, its addresses, data and timestamps are illustrative (demonstration data). The scenario shows the system flow and does not refer to any real event.
Chain:
1 REPORT2 EVIDENCE3 STATUS4 CLASSIFY5 FLAGS6 PLAYBOOK7 ACTION8 VALIDATE9 REPORT
Step 1 — Report. A branch employee reports an email impersonating "Bank Security" with a link to a fake login gateway. Channel: Incident Intake. Record INC-DEMO-7742 created. SIMULATION
Step 2 — Evidence. Attached to the record: a copy of the email (headers), the fake domain URL bank-secure-login[.]xyz, a screenshot of the page. Every artefact hashed (SHA-256) + timestamp → evidence status CONFIRMED. Chain of custody started.
Step 3 — Status. The event is materially confirmed (the email exists + the domain is live). The record moves from PUBLIC CLAIM to CONFIRMED.
Step 4 — Classification. Classification Engine: category = phishing / PhaaS (Phishing-as-a-Service), vector = email, priority = P1 (active campaign, target = customer credentials, SLA 24h).
Step 5 — Legal flags. Set: GDPR_PERSONAL_DATA (customer data targeted), CRITICAL_INFRA (bank), NIS2_RELEVANT, LAW_ENFORCEMENT (suspected crime). GDPR_BREACH = for DPO assessment (whether data was actually captured).
Step 6 — Playbook. The phishing playbook runs: recipient identification, domain takedown, URL blocking at the gateways, warning notice, reset for exposed accounts.
Step 7 — Action. Report to the registrar/hosting (takedown), URL added to the proxy/mail blocklist, forced password reset and re-SCA for accounts that clicked the link. Every action logged in the trace.
Step 8 — Validation. Confirmation: domain unreachable (takedown OK), no further clicks, no trace of a successful session takeover. DPO assesses: no proof of data leak → GDPR_BREACH = false (decision in the HITL register).
Step 9 — Report. Generated: a NIS2 entry (if the materiality threshold is met), a note to the DORA incident register, an evidence package (14 artefacts, sealed hash) for audit. GDPR art. 33 not triggered (no breach) — the decision is documented.
4. What the auditor sees after closure
14
Evidence artefacts
hash-sealed SIM.
P1
Priority / SLA 24h
documented
4
Legal flags
with justification
1
HITL decision
GDPR_BREACH=false, justified
The values above are SIMULATION — demonstration data from the described scenario.
5. Why evidence-first minimises legal and audit risk
- Accountability before the regulator. The supervisor / data-protection authority / AI market authority receives a non-repudiable trail of decisions — not an after-the-fact narrative.
- Resistance to challenge. Hash + timestamp + chain of custody make the material usable in proceedings; no "word against word".
- Honest uncertainty. What cannot be proven is explicitly marked GAP — the bank does not report as fact anything without backing, which removes the risk of misleading the authority.
- Proportionate response. The decision to notify (e.g. GDPR art. 33) rests on evidence, not fear — fewer false alarms, fewer unnecessary notifications.
- Shorter MTTR. A ready playbook + a pre-filled report shorten the time from detection to action and to filing within the statutory deadline.
- Control over AI. A tool firewall and human approval for payment actions limit the risk of an agent acting autonomously on the bank's critical assets.
Doctrine claim ≤ proof: no statement in the bank's report exceeds the strength of the evidence behind it. This is both compliance (accountability) and operational hygiene (fewer wrong decisions).
6. An honest note on maturity
Product status: K0NSULT /ai-truth/ipIII v1.0 is a reference skeleton (architecture + patterns + a flow demonstration), not a productionised bank SOC system. The whole scenario on this page is SIMULATION. A bank deployment requires: integration with SIEM/EDR and identity systems, calibration of thresholds and SLAs, legal review of the templates by the bank's DPO/counsel, and resilience testing consistent with DORA. We state this honestly — evidence-first applies to claims about the product itself too.
7. Links to boards and modules
Point of contact for institutions: via the ai-truth portal. K0NSULT Sp. z o.o., NIP 5253089872, KRS 0001239441.