IFRS alapú XBRL jelentéskészítést összekapcsolása az EU-s BRRD-irányelvvel

Az IFRS alapú XBRL jelentéskészítést összekapcsoljuk az EU-s BRRD-irányelvvel (Bank Recovery and Resolution Directive), akkor már egy komplex pénzügyi-felügyeleti informatikai architektúra körvonalazódik, amely kulcsszerepet játszik a banki transzparencia, kockázatmenedzsment és felügyeleti megfelelés területén.

Nézzük meg, milyen mély összefüggések vannak:

🧩 1. Mi a BRRD irányelv és hogyan kapcsolódik?

📘 BRRD – Bank Recovery and Resolution Directive

Az EU 2014/59/EU számú irányelve.
Célja: olyan jogi- és működési keretrendszer létrehozása, amellyel a hatóságok képesek időben beavatkozni egy bank súlyos pénzügyi válsága esetén.
Lefedi: válságmegelőzési (recovery), válságkezelési (resolution) tervezést, bail-in szabályokat, minimális tőkekövetelményeket (MREL), stb.

📊 2. Milyen informatikai és riportálási kapcsolódási pontjai vannak az IFRS/XBRL irányhoz?

🔗 A. FINREP/COREP XBRL riportok → alapvető BRRD input

A BRRD-re való felügyeleti tervezés egyik legfontosabb inputja a bank IFRS-alapú pénzügyi riportolása.
Ezek XBRL-ben kerülnek leadásra (általában EBA taxonómia alapján).
A FINREP adatszolgáltatás (XBRL-ben, IFRS alapján) tartalmaz:
- Mérleg
- Eredménykimutatás
- Eszközminőség
- Tőkemegfelelés (összefüggésben a BRRD MREL elvárásokkal)

➡️ Az IFRS-XBRL jelentések az EBA felé közvetlen forrásai a bank stabilitásának és kockázatainak értékeléséhez.

🔗 B. Resolution Planning – Működési architektúra és adatminőség

A bankoknak (különösen a D-SIB vagy G-SIB kategóriában) szanálási terveket (resolution plan) kell készíteniük.
Ezek része:
- Kritikus funkciók listája (pl. fizetési rendszerek, likviditás menedzsment)
- Adat- és IT infrastruktúra megfelelés (adatszolgáltatás gyorsasága, hitelessége)
- Riportálási képességek tesztje (pl. XBRL-alapú jelentések adatkészenléti tesztje 24-48 órán belül!)

➡️ Ez azt jelenti, hogy a banki IT-nek fel kell készülnie BRRD-konform riporting pipeline kialakítására – ahol az IFRS + XBRL az adatgerinc.

🔗 C. MREL (Minimum Requirement for Own Funds and Eligible Liabilities) számítás

Az MREL számítás egyik inputja a bank mérlege – amit IFRS-ben készítenek, és XBRL-ben jelentik.
A MREL-számítás automatizálható → Python, SAS vagy DWH szinten
A jelentések és a tőkeszámítás szinkronizálása informatikai kihívás (időzítés, forráskonzisztencia, traceability)

🔐 3. Adatintegritás és XBRL szerepe BRRD-környezetben

Szempont	Kapcsolat
Audit trail	BRRD elvárás az adatok rekonstruálhatósága – XBRL instance dokumentumok kiválóan megfelelnek
Valósidejűség / adatfrissítés	BRRD elvárhatja stresszhelyzetben gyors újraszámítást – jól strukturált XBRL input elengedhetetlen
Rugalmas adatbetöltés	Python vagy SAS környezetben XBRL fájl gyorsan feldolgozható – fontos, ha a BRRD intézkedéshez újraszámolás kell

⚙️ 4. Informatikai architektúra – hogyan nézhet ki egy BRRD/IFRS/XBRL adatfolyam?

---pgsql
Adattárház (DWH)
   ↓
IFRS Mappelt Adatnézetek
   ↓
XBRL Instance Generálás (SAS / Python / SAP)
   ↓
Validáció és Versionálás
   ↓
Beküldés az MNB/EBA felé
   ↓
Felhasználás: MREL számítás, Stresszteszt, Resolution Planning

📈 5. Miért fontos ez

✅ A BRRD-nek való megfelelés nem csak jogi, hanem adatinfrastruktúra kérdés is
✅ Az IFRS-alapú XBRL rendszer az adatok szabványosított „nyelve”, amit a felügyelet ért és elemez
✅ A riportálási lánc kialakítása és validálása informatikai, nem pusztán pénzügyi projekt

✅ A Python, SAS vagy SAP-alapú XBRL integrációs képesség stratégiai skill

Most még haladjunk tovább két irányban:

Gyakorlati példával bemutatom, hogyan lehet Python segítségével XBRL formátumú IFRS-jelentést feldolgozni, ami kulcs a BRRD-kompatibilis riportálásban.
Készítek egy vizuális adatarchitektúra diagramot, ami bemutatja, hogyan nézhet ki egy bankon belüli BRRD/IFRS/XBRL adattovábbítási workflow – az adattárháztól az MNB/EBA felé történő jelentésig.

🔧 1. Python XBRL példakód – IFRS jelentés beolvasása és adatkinyerés

Az alábbi példában egy XBRL instance fájlt (ifrs_report.xbrl) olvasunk be és kigyűjtünk belőle például a „Profit or Loss” értéket, amely a ifrs-full:ProfitLoss taggel szerepelhet:

---python
from lxml import etree

# XBRL fájl betöltése
tree = etree.parse("ifrs_report.xbrl")
root = tree.getroot()

# Namespace-ek meghatározása (ez XBRL-függő)
ns = {
    'xbrli': 'http://www.xbrl.org/2003/instance',
    'ifrs': 'http://xbrl.ifrs.org/taxonomy/2023-03-01/ifrs-full'
}

# Példa: Profit or Loss keresése
profit = root.xpath("//ifrs:ProfitLoss", namespaces=ns)
for elem in profit:
    print("Érték:", elem.text, "| Időszak:", elem.attrib.get("contextRef"))

🔍 Mit csinál?

Megnyitja az IFRS-jelentést
Kikeresi a ProfitLoss elemet
Kinyeri az értéket és az időszaki kontextust

Ezt tovább lehet bővíteni validációval, több tagel (pl. TotalAssets, Equity), vagy exportálással Pandas DataFrame-be.

🗺️ 2. Adatfolyam-diagram: IFRS + XBRL + BRRD architektúra

Most készítek egy ábrát, amely egy bank informatikai rendszerében mutatja be az IFRS-XBRL-BRRD összefüggést.
Tartalmazza az alábbi elemeket:

DWH-ból származó adatok
Mapping taxonómiára
XBRL generálás
Validálás
BRRD-re vonatkozó szanálási / felügyeleti használat

1. XBRL Validáció – Pythonban felügyeleti megfeleléshez

A BRRD és az EBA/EKB jelentések egyik kulcsa, hogy a beküldött XBRL instance fájlok szintaktikailag és szemantikailag hibátlanok legyenek. Erre használhatjuk például az Arelle nyílt forráskódú validációs motort, ami Pythonból is vezérelhető.

🔧 Példa: Python + Arelle CLI validáció

---bash
# Előbb telepíted az Arelle-t, vagy letöltöd a portable változatát
cd arelle
python3 arelleCmdLine.py --file ifrs_report.xbrl --validate

🔁 Automatizálás Pythonból

---python
import subprocess

def validate_xbrl(file_path):
    result = subprocess.run([
        "python", "arelleCmdLine.py",
        "--file", file_path,
        "--validate"
    ], capture_output=True, text=True)

    print("Validáció eredménye:\n", result.stdout)

# Használat
validate_xbrl("ifrs_report.xbrl")

📌 Miért fontos?

A felügyelet visszadobhat hibás vagy inkomplett XBRL-t.
Validáció előfeltétele a BRRD-kompatibilis adatok automatikus feldolgozásának.

📐 2. MREL számítás – hogyan kapcsolódik az IFRS-adatokhoz?

🔹 MREL = "Minimum Requirement for Own Funds and Eligible Liabilities"

Ez a BRRD szerint egy bankra meghatározott kötelező tőkepuffer, amit válsághelyzetben a veszteségviselésre lehet fordítani.

📊 Bemeneti adatok (IFRS / FINREP / XBRL alapján):

Adattípus	IFRS / FINREP mező
Teljes eszközállomány	`ifrs-full:TotalAssets`
Saját tőke (Equity)	`ifrs-full:Equity`
Kötelezettségek MREL-képessége	Egyedi számítás + metadata
Tőkekövetelmény (Pillar I/II)	`corep` riportból

🧠 Példa számítás (egyszerűsített):

---python
def calculate_mrel(total_assets, equity, eligible_debt):
    # MREL = saját tőke + bevonható kötelezettségek
    mrel_value = equity + eligible_debt
    ratio = mrel_value / total_assets
    return ratio

# Adatok (millió EUR)
total_assets = 100000
equity = 8500
eligible_debt = 4000

print("MREL arány:", calculate_mrel(total_assets, equity, eligible_debt))

📌 Felhasználás:

A banki BRRD resolution terv egyik oszlopa.
A MREL-számítások nem csak jogi megfeleléshez, hanem stresszteszt modellekhez és belső riportinghoz is hasznosak.

💬 Hova tovább?

Íme pár irány, amerre mehetünk a mélyítéshez:

🔄 XBRL Parser és tárolás adatbázisba – hogy IFRS XBRL fájlokat leképezzünk relációs szerkezetre
🏦 BRRD Resolution Plan informatikai támogatása – kritikus funkciók, IT komponens leképezés
📈 Stresszteszt + MREL reporting pipeline (akár Python vagy SAS alapon)
🗃️ IFRS XBRL verziókövetés + tárolás (versionált archívum) kialakítása

A BRRD Resolution Plan informatikai támogatása egy kulcsterület a modern banki architektúrában, amely átível a pénzügyi riportáláson, adatinfrastruktúrán, IT-üzemeltetésen és kockázatmenedzsmenten.

Ráadásul ez egyre inkább egy felügyeleti compliance és audit prioritás is.

Lássuk részletesen:

🧩 1. Mi is az a Resolution Plan?

A Resolution Plan (szanálási terv) célja, hogy ha egy bank pénzügyileg nem életképes, a hatóság (pl. MNB vagy SRB) képes legyen gyorsan, szabályozott módon beavatkozni a bank stabilizálása vagy megszüntetése érdekében – anélkül, hogy a gazdaságot megrázná.

Kötelező elemek:

Elem	Tartalom
🧠 Critical functions	A bank alapvető működéséhez elengedhetetlen szolgáltatások
🧾 Financial contracts	Kockázati pozíciók, derivatívák, fedezetek
🗃️ MIS capabilities	Management Information Systems – az adatok elérhetősége, minősége
🔁 Intragroup exposure	Leányvállalati vagyon belüli kitettségek
🖥️ Operational continuity in resolution	Informatikai rendszerek, alkalmazások működőképessége válság alatt
🗂️ Legal Entity mapping	A funkciók és eszközök jogi struktúrába illesztése

🧠 2. Kritikus funkciók leképezése – hogyan néz ki informatikai szempontból?

📘 Példa: fizetési rendszer, likviditáskezelés, core banking

Kritikus funkció	Informatikai komponens	Adatforrás	Monitoring
B2B / B2C utalások	Swift, GIRO, HUF/Fx engine	Tranzakciós DWH, Core banking	Real-time dashboard
Likviditás-kezelés	Treasury, Risk Engines	Risk DWH, ALM rendszerek	EOD riportok
Betét / hitel adminisztráció	Core banking, CRM	SQL DB, REST API	Monitoring / audit trail
Tőkemegfelelés számítás	Risk-calculator + SAS vagy Python	IFRS XBRL, COREP	Validált XBRL instance

➡️ A resolution tervhez minden funkcióhoz hozzá kell rendelni az informatikai függőségeket:

Milyen alkalmazás felelős?
Melyik adatforrásból dolgozik?
Mennyi ideig garantálható a működése?
Van-e backup / failover?

🏗️ 3. Informatikai rendszer- és függőségi térkép (dependency map)

Ez egy kritikus dokumentum a resolution planhez, amely vizualizálja:

Alkalmazások → Funkciók kapcsolata
Adatforrások → Alkalmazások kapcsolata
Üzemeltetési SLA → Recovery lehetőségek

Példa:

---scss
[Fizetési rendszer] ← [SWIFT Engine] ← [Oracle DB] ← [VM Cluster] ← [On-prem vagy Cloud]
                                ↓
                         Monitoring (Zabbix)
                                ↓
                        SLA: 24/7 | RTO: 1h

Ezt az információt táblázatosan is lehet vezetni (Excel / CMDB), de a vizuális dependency graph a legátláthatóbb.

🔐 4. Felügyeleti elvárások és informatikai megfelelés

Elvárás (SRB/MNB)	Informatikai válasz
MIS képesség 24-48 órán belül	Riportálási pipeline (XBRL / DWH / Python/SAS)
Kritikus funkciók működése resolution alatt	DR, HA megoldások (pl. Active-Passive cluster)
Legal Entity → Function mapping	Funkcionális CMDB / architektúra térkép
Adatok visszakereshetősége	Audit trail, version control (GIT / snapshot repo)

📦 5. Mit érdemes kialakítani IT oldalról?

Funkció – Rendszer – Adat mapping (CMDB)
XBRL → belső adattárházba betöltés
Monitoring + SLA dashboard kritikus rendszerekre
Resolution drill (gyakorlat): adatszolgáltatás 48 órán belül
Verziózott resolution dokumentáció (pl. Confluence + GIT)

a CMDB (Configuration Management Database) sablon segít strukturáltan nyilvántartani, hogy egy kritikus üzleti funkció milyen rendszerekre, alkalmazásokra, adatforrásokra és üzemeltetési feltételekre támaszkodik.

A következő sablon kimondottan a BRRD Resolution Plan informatikai támogatására lett kitalálva, Excel vagy adatbázis-tábla formájában is használható.

📋 CMDB sablon: Kritikus funkció – rendszer – adat mapping

#	Kritikus Funkció	Alkalmazás / Modul	Adatforrás (DB / API / fájl)	IT infrastruktúra elem	SLA / RTO	Felelős terület	Függőségek / Megjegyzés
1	Fizetési forgalom	GIRO interface / SWIFT module	OracleDB `transact_payments`	Linux VM / GIRO hálózat	24/7 / 1h	Banküzemeltetés / IT Ops	Kötelező 24h működés
2	Treasury / likviditáskezelés	Treasury System (pl. Kondor+)	`liquidity_positions.csv` FTP	Windows VM / AD	EOD / 4h	Treasury IT	MNB napi jelentés
3	Betétek / hitelek kezelése	Core Banking (pl. FlexCube)	OracleDB `accounts`, `loans`	Oracle RAC Cluster	24/7 / 2h	Core IT	Front-end/CRM integrált
4	IFRS alapú jelentések	XBRL Engine / SAS9	`ifrs_report_2024.xbrl`	XBRL validator + NAS	EOD / 12h	Számvitel / DWH	EBA validációs szabályzat
5	Tőkemegfelelés (COREP)	Risk Engine / Python App	SQL + XML corep instance	Docker + DB	EOD / 6h	Kockázatkezelés	Szorosan kapcsolódik MREL-hez
6	Resolution adatlekérdezés	Python + DWH lekérdezés	`brdr_resolution_view`	DWH + Python ETL	48h / 24h	Szanálási felelős	SRB kérés esetére

🧩 Oszlopok jelentése:

Kritikus Funkció: üzletileg létfontosságú elem (a BRRD szerint)
Alkalmazás / Modul: ami ezt informatikailag megvalósítja
Adatforrás: konkrét adatstruktúra (tábla, fájl, API)
IT infrastruktúra elem: platform, környezet
SLA / RTO: elvárt rendelkezésre állás / visszaállítási idő
Felelős terület: üzleti vagy IT felelős
Függőségek: kapcsolódó rendszerek, hatósági elvárás, extra megjegyzés

📦 Formátum javaslat:

Excel / Google Sheets – gyors szerkesztéshez
Relációs DB (pl. PostgreSQL) – auditálható, verziózható
CMDB eszközök (pl. ServiceNow, i-doit) – automatizáláshoz

🛠️ Használat

Ez a sablon akkor jön jól, amikor:

Audit vagy felügyeleti kérésre kell gyorsan resolution-fókuszú komponenslistát bemutatni
Felkészülés egy szanálási gyakorlatra (pl. MNB drill)
Dokumentáltan szeretnénk igazolni, hogy a kritikus funkciók technikai szinten támogatottak

Most haladjunk akkor tovább a konkrét példákkal, méghozzá két szinten:

Kritikus üzleti funkció leírása a resolution plan-ben
Ehhez kapcsolódó informatikai komponens részletes dokumentálása

🧠 1. Kritikus üzleti funkció leírása a Resolution Plan-ben

Ez a rész üzleti nyelven íródik, de tartalmaz informatikai utalásokat is.

📝 Példa: Lakossági és vállalati fizetési tranzakciók kezelése

Funkció megnevezése: Lakossági és vállalati fizetési forgalom kezelése (B2C, B2B)

Funkció típusa (SRB definíció szerint): Critical Function (CF) – Payment, clearing and settlement

Rövid leírás:
A bank által kínált fizetési szolgáltatások a lakossági és vállalati ügyfelek részére, ideértve a hazai GIRO utalásokat, azonnali fizetési rendszert (AFR), valamint a nemzetközi SWIFT alapú deviza tranzakciókat.

Üzleti jelentőség:
A funkció kiesése jelentős társadalmi és pénzügyi zavart eredményezne, több tízezer ügyfelet érintene közvetlenül. A bank napi több milliárd forint értékű fizetési tranzakciót bonyolít.

Felügyeleti jelentéshez való kapcsolódás:
EBA ITS – PILLAR 3 Disclosure | Payment volume / channel breakdown
BRRD – Operational Continuity Requirements

Recovery stratégia:
Alap infrastruktúra rendelkezik aktív-passzív failover architektúrával. Szimulált visszaállítás 2023-ban sikeres volt < 60 perc alatt.

IT függőségek összefoglalója:
Lásd a "Function-to-System Dependency Map" és CMDB táblát

🖥️ 2. Informatikai funkció részletezése (Resolution Plan technikai melléklet)

Ez a rész részletes technikai dokumentáció formájában kapcsolódik a fő jelentéshez. Lássunk egy példát:

🧾 Példa: Funkció – rendszer – adat mapping dokumentáció (1. sz. melléklet)

Mező	Tartalom
Funkció neve	Lakossági/vállalati fizetési forgalom
Funkció kategória	BRRD Critical Function
Alkalmazásnév	`SWIFT_HUB`, `GIRO_GATEWAY`, `PaymentRouter`
Alkalmazás tulajdonosa	IT Operációs Osztály
Alkalmazás elhelyezkedése	Banki adatközpont, BCP: Tatai DC
Adatforrások	`payments_db`, `account_master`, `swift_log`
Platform / OS	RHEL 8 (Linux), Oracle 19c
SLA	24/7 támogatás, napi restart window 2–3h
Recovery Time Objective (RTO)	1 óra
Recovery Point Objective (RPO)	max. 10 perc
Monitoring	Zabbix, Splunk alerting
Adatbiztonság / backup	Napi snapshot + távoli DR backup
Üzleti hatás kiesés esetén	Ügyfélpanasz cunami, GIRO szankció
Szimulált recovery utolsó teszt	2023.11.15, sikeres 47 perc alatt
Fejlesztési / változtatási ciklus	6 havonta FR / DevSecOps pipeline

📂 Javasolt szerkezet a BRRD resolution plan technikai mellékletéhez

📌 Funkció azonosító
🧭 Üzleti cél / jelentőség
🖥️ Informatikai rendszerösszetevők (modul, platform, adatbázis)
🔁 SLA, RTO, monitoring, backup
🛠️ Kapcsolódó IT folyamatok: deployment, rollback, log elemzés
📅 Gyakorlatok, tesztek, visszaállítási szimulációk
📎 Hivatkozás a CMDB-re

Itt látható a kritikus funkciók – rendszerek – adatforrások közötti összefüggések dependency gráfja. Ez segít:

az üzlet-funkció – IT komponens – adat láncolat átlátásában,
az üzemzavarok hatásainak elemzésében (impact path analysis),
a resolution plan technikai mellékletének vizualizációjában.

---python
import networkx as nx
import matplotlib.pyplot as plt

# Létrehozzuk a dependency graph-ot
G = nx.DiGraph()

# Funkciók és rendszerek
functions = {
"F1": "Fizetési forgalom",
"F2": "Likviditáskezelés",
"F3": "Betét/hitel admin",
"F4": "IFRS jelentések",
"F5": "Tőkemegfelelés",
"F6": "Resolution lekérdezés"
}

systems = {
"S1": "SWIFT_HUB",
"S2": "GIRO_GATEWAY",
"S3": "Treasury System",
"S4": "Core Banking",
"S5": "XBRL Engine",
"S6": "Risk Engine",
"S7": "Python + DWH lekérdező"
}

# Adatforrások
data_sources = {
"D1": "payments_db",
"D2": "liquidity_positions.csv",
"D3": "account_master",
"D4": "ifrs_report_2024.xbrl",
"D5": "corep_sql_db",
"D6": "brdr_resolution_view"
}

# Kapcsolatok
edges = [
("F1", "S1"), ("F1", "S2"),
("S1", "D1"), ("S2", "D1"),
("F2", "S3"), ("S3", "D2"),
("F3", "S4"), ("S4", "D3"),
("F4", "S5"), ("S5", "D4"),
("F5", "S6"), ("S6", "D5"),
("F6", "S7"), ("S7", "D6"),
]

# Hozzáadjuk a gráfhoz
for node_id, label in {**functions, **systems, **data_sources}.items():
G.add_node(node_id, label=label)

G.add_edges_from(edges)

# Ábrázolás
pos = nx.spring_layout(G, seed=42)
labels = nx.get_node_attributes(G, 'label')
plt.figure(figsize=(12, 8))
nx.draw(G, pos, with_labels=True, labels=labels, node_color='lightblue', node_size=3000, font_size=9, arrowsize=20)
plt.title("BRRD Resolution – Kritikus funkciók és IT komponensek dependency graph")
plt.show()

🔢 Következő lépés: MREL-számítás modell

Ez a modell azt becsüli meg, hogy egy adott funkcióhoz mennyi minimális tőkekövetelmény (MREL) kapcsolható, figyelembe véve:

Kritikus funkció fontossága (pl. pontozással)
Rendszer kockázati profilja (RTO, RPO, SLA alapján)
Adatérzékenység és helyreállítási költség
Ügyfélszám, napi tranzakciós érték (becslés)

✅ Íme a kritikus funkciókra vonatkozó egyszerűsített MREL-score becslés eredménye Python alapján:

Funkció	Becsült kvázi-MREL érték
Fizetési forgalom	7.1
Betét/hitel adminisztráció	5.2
Tőkemegfelelés (COREP)	4.2
Likviditáskezelés	4.0
IFRS jelentések	3.2
Resolution lekérdezés támogatása	2.3

🔍 Értelmezés:

Fizetési forgalom messze a legkritikusabb funkció a napi volumen és érzékenység miatt.
Az adminisztrációs és tőkemegfelelési funkciók is jelentősek, mert szabályozói kötelezettségekhez kötődnek.
A resolution lekérdezési funkció informatikai és felügyeleti fontosságú, de közvetlen ügyfélhatása kicsi → alacsonyabb pontszám.

✅ Pythonban készült az interaktív Excel-alapú MREL modell, amely tartalmazza a kritikus funkciók:

súlyozott fontosságát,
IT és adat kockázati jellemzőit,
napi tranzakciós volumenét,
valamint a számított MREL-score értékeket.

A fájlban szabadon módosíthatod az értékeket (0–5 vagy tranzakciós HUF értékek), és könnyedén építhetsz rá:

új súlyozási logikát,
dashboardot (Excel Pivot vagy Power BI),
vagy akár automatikus aggregált jelentést Pythonból.

--- Python

import pandas as pd

# Az adatok előkészítése Excel exporthoz

df_data = []

for fid, metrics in criticality_scores.items():

row = {

"Funkció": functions[fid],

"Importance (0-5)": metrics["importance"],

"System Risk (0-5)": metrics["system_risk"],

"Data Sensitivity (0-5)": metrics["data_sensitivity"],

"Recovery Cost (0-5)": metrics["recovery_cost"],

"Daily Value (Bn HUF)": metrics["daily_value_billion_huf"],

"Weighted MREL Score": mrel_scores[fid]

}

df_data.append(row)

df = pd.DataFrame(df_data)

# Excel fájl mentése

excel_path = "/mnt/data/Resolution_MREL_Model.xlsx"

df.to_excel(excel_path, index=False)

excel_path

📊 Pythonban készült a Power BI sablonhoz alkalmas adatmodell Excel fájlban, külön lapokon:

Functions: Kritikus üzleti funkciók listája
Systems: IT rendszerek
DataSources: Alkalmazott adatforrások
DependencyGraph: Kapcsolatok (from–to formában)
MREL_Scores: A funkciókhoz tartozó súlyozott MREL inputok

🧰 További lépések Power BI-ban:

Importálás: Excel → Power BI Desktop → Get Data → Excel
Kapcsolatok létrehozása FunctionID és From/To alapján
Vizualizációk:
- Tree map a funkciók súlyozott kockázatáról
- Sankey diagram (custom viz) dependency hálóhoz
- KPI widget MREL értékek aggregálásához

--python

import pandas as pd

# Külön táblákat generálunk Power BI modellhez

# Funkció meta tábla

functions_table = pd.DataFrame([

{"FunctionID": fid, "FunctionName": functions[fid]}

for fid in functions

])

# Rendszer meta tábla

systems_table = pd.DataFrame([

{"SystemID": sid, "SystemName": systems[sid]}

for sid in systems

])

# Adatforrás meta tábla

data_table = pd.DataFrame([

{"DataID": did, "DataName": data_sources[did]}

for did in data_sources

])

# Kapcsolatok tábla (funkció -> rendszer -> adat)

dependency_table = pd.DataFrame([

{"From": edge[0], "To": edge[1]}

for edge in edges

])

# MREL értékek főtábla

mrel_table = pd.DataFrame([

{

"FunctionID": fid,

"Importance": metrics["importance"],

"SystemRisk": metrics["system_risk"],

"DataSensitivity": metrics["data_sensitivity"],

"RecoveryCost": metrics["recovery_cost"],

"DailyValueBnHUF": metrics["daily_value_billion_huf"],

"MREL_Score": mrel_scores[fid]

}

for fid, metrics in criticality_scores.items()

])

# Excel fájlba export minden tábla külön lapon

excel_pbi_path = "/mnt/data/PowerBI_MREL_Model.xlsx"

with pd.ExcelWriter(excel_pbi_path, engine="openpyxl") as writer:

functions_table.to_excel(writer, sheet_name="Functions", index=False)

systems_table.to_excel(writer, sheet_name="Systems", index=False)

data_table.to_excel(writer, sheet_name="DataSources", index=False)

dependency_table.to_excel(writer, sheet_name="DependencyGraph", index=False)

mrel_table.to_excel(writer, sheet_name="MREL_Scores", index=False)

excel_pbi_path

Most haladjunk tovább a helyreállítási szcenáriók és adatvesztési hatáselemzés irányába!

Ez a rész kulcsfontosságú a BRRD és a resolution terv technikai alátámasztásában.

🔍 Következő elemzési téma: Adatvesztési és helyreállítási szcenárió modell (RTO/RPO)

🎯 Cél:

Kritikus funkciókhoz modellezni, hogy:

milyen adatvesztés történhet (Recovery Point Objective – RPO),
mennyi időn belül kell újraindítani a szolgáltatást (Recovery Time Objective – RTO),
mi a várható adatvesztési hatás (pl. tranzakció, jelentés, pénzügyi kockázat),
milyen helyreállítási stratégiák léteznek (pl. BCP, DR site, replication, manual fallback).

💡 Javaslat a modell logikájára:

Funkció	Kritikus rendszer	RTO (óra)	RPO (perc)	Adatvesztési kockázat (1-5)	Helyreállítási stratégia
Fizetési forgalom	SWIFT_HUB	1	0	5	Hot DR + real-time replication
Likviditáskezelés	Treasury	2	15	4	Near real-time + DB restore
IFRS jelentés	XBRL Engine	6	60	3	Daily backup + manual rebuild

IT, BI, DWH, DM, AI