antifragile/antifragile-consulting/reference/vertical-banking.md

Vertical Reference: Banking and Financial Services

"A bank's trust is its only real asset. Technical debt in security is a withdrawal from that account."

This document adapts the antifragile rapid modernisation approach for banking and financial services—one of the most regulated, most targeted, and most technologically heterogeneous sectors. Banks face adversaries ranging from criminal syndicates to nation-states, while navigating DORA, PSD2, GDPR, NIS2, and national banking regulations.

---

The Banking Security Context

What Makes Banking Different

Factor	Enterprise Default	Banking Reality
Regulatory density	Moderate	Extreme (DORA, PSD2, GDPR, NIS2, Basel, national banking laws)
Adversary motivation	Financial (ransomware, fraud)	Financial + espionage + destabilization
Transaction speed	Batch, daily	Real-time, 24/7, instant payments
Legacy systems	5-10 years old	20-40 years old (mainframes, COBOL)
Third-party reliance	Moderate	High (fintech APIs, payment processors, SWIFT)
Data sensitivity	Personal data	Personal + financial + transaction patterns + behavioural biometrics

The Legacy Problem

Many banks run core banking systems on mainframes or mid-range systems that predate modern security architecture. These systems:

• Use legacy authentication (no MFA natively)
• Log minimally or opaquely
• Have no API layer; integration occurs via file transfer or terminal emulation
• Run on operating systems with limited patch support

Our approach does not demand legacy replacement. It demands compensating controls and isolation architecture.

---

Regulatory Landscape

DORA (Digital Operational Resilience Act) — EU

Effective January 2025, DORA imposes comprehensive ICT risk management requirements on EU financial entities.

DORA Requirement	Antifragile Application
ICT risk management framework (Article 6)	Kill chain analysis as primary risk methodology; T0 asset classification for critical banking systems
ICT-related incident management (Article 10)	Sub-hour detection and containment targets; automated reporting to lead overseer
Digital operational resilience testing (Article 11)	Quarterly recovery drills for core banking; annual red team; threat-led penetration testing (TLPT)
ICT third-party risk (Article 12)	Vendor exit architectures for all critical ICT providers; contract clawbacks for security failures
Information sharing (Article 14)	Anonymized incident signals shared via sector ISACs; defensive AI trained on collective threat data

PSD2 (Revised Payment Services Directive)

PSD2 Requirement	Security Implication
Strong Customer Authentication (SCA)	MFA for payment initiation and account access
Dynamic linking	Authentication code must be specific to transaction amount and payee
Secure communication	TLS 1.2+, mutual authentication for TPP APIs
Access for TPPs (Third Party Providers)	New API attack surface; strict OAuth scope control

NIS2 for Systemic Banks

Systemic banks fall under NIS2 as "essential entities" with:

• 24-hour incident reporting to CSIRT
• Supply chain security obligations
• Board-level accountability for cybersecurity

National Regulations

Jurisdiction	Key Regulation
Germany	BAIT (BAIT-Rahmen), MaRisk
UK	CBEST, STAR, SYSC
US	FFIEC guidelines, SOX, GLBA
Switzerland	FINMA Circular 2023/1

---

The Antifragile Posture for Banking

Pillar 1: Structural Decoupling — Core Banking Isolation

Principle: The core banking system must be structurally isolated from internet-facing channels, third-party APIs, and general corporate IT.

Antifragile Moves:

Layer	Isolation Requirement
Channel layer	Internet banking, mobile apps, open banking APIs → DMZ, WAF, API gateway
Integration layer	API gateway, middleware, ESB → validates, transforms, rate-limits all traffic
Core layer	Core banking, payments engine, general ledger → no direct internet; access only via integration layer
Data layer	Customer databases, transaction history → encrypted at rest; access via service accounts only
Reporting layer	Data warehouse, BI, regulatory reporting → read-only from core; no write-back

The Conversation:

"Your core banking system is a Tier 0 asset. It should not know the internet exists. Every request must pass through an integration layer that validates, logs, and rate-limits. If a mobile app vulnerability is exploited, the adversary should hit the API gateway—not the general ledger."

Pillar 2: Optionality Preservation — Fintech and TPP Independence

Principle: Open banking and fintech integration create dependencies. The bank must retain the option to disconnect, replace, or limit any third party without operational paralysis.

Antifragile Moves:

• API abstraction layer: All TPP connections via bank-controlled API gateway; no direct TPP-to-core connections
• Scope-limited OAuth: TPP tokens granted only for specific accounts, specific data sets, specific time windows
• Circuit breakers: Automatic disconnection of TPPs exhibiting anomalous behaviour (high request rates, unusual data access patterns)
• TPP risk register: Every connected TPP rated for security maturity with quarterly re-assessment
• Exit architecture: Technical and contractual ability to revoke TPP access within 1 hour

Pillar 3: Stress-to-Signal Conversion — Fraud as Intelligence

Principle: Every fraud attempt, successful or not, is free threat intelligence. The bank must learn faster than the adversary adapts.

Antifragile Moves:

• Real-time fraud detection: Local AI models trained on proprietary transaction data to detect anomalies without cloud exfiltration
• Fraud-to-structure pipeline: Every confirmed fraud case must produce at least one control improvement
• Behavioral biometrics: Device fingerprinting, typing cadence, mouse movement patterns—signals that improve with volume
• Mule account detection: Graph analysis on account opening and transaction patterns to identify money laundering networks

Pillar 4: Sovereign Intelligence — Payments Data Never Leaves

Principle: Payment transaction data reveals economic behaviour, business relationships, and operational patterns. It must never train a third-party AI.

Antifragile Moves:

• Local fraud models: Train on transaction history, merchant categories, geolocation, and temporal patterns locally
• On-premise transaction monitoring: AML/sanctions screening engines run on bank-controlled hardware
• Closed-loop analytics: Customer segmentation, product recommendation, and risk scoring using local models
• Data residency by design: Primary data storage in national or EU jurisdiction; encryption keys in HSM under bank control

The Conversation:

"Your payments data is not just customer data. It is a map of your economy. Sending it to a cloud AI for 'fraud optimization' is not a technology partnership. It is an intelligence transfer. Local models. Local hardware. Local keys."

Pillar 5: Asymmetric Payoff — Resilience Over Perfection

Principle: Banks cannot prevent all fraud or all attacks. The antifragile bank designs systems where small security investments yield disproportionate reductions in catastrophic risk.

Antifragile Moves:

• Segmented transaction limits: Real-time limits by channel, geography, time, and customer segment; limits the blast radius of compromised credentials
• Synthetic account testing: Maintain honeypot accounts that alert on any access attempt
• Rapid account freezing: Sub-60-second ability to freeze accounts, revoke tokens, and block cards
• Distributed ledger backup: Critical transaction records replicated to immutable, geographically distributed storage

---

The Rapid Modernisation Plan: Banking Variant

Phase 1: Hygiene (Days 0-30) — Banking-Specific Additions

In addition to standard hygiene:

Action	Owner	Deliverable	Regulatory Link
Inventory all systems processing payment data	Security / Architecture	PCI-DSS / payment system asset inventory	PSD2, PCI-DSS
Map all open banking / TPP connections	API Team	TPP connection matrix with data flows	PSD2
Audit SWIFT infrastructure access and messaging	Security / Treasury	SWIFT CSP compliance gap analysis	SWIFT CSP
Verify data residency for customer and transaction data	Legal / Cloud	Data residency attestation	GDPR, DORA
Inventory cryptographic key material and HSMs	Security	Key management inventory	DORA, national crypto regs

Phase 2: Control (Days 30-60) — Banking-Specific Additions

Action	Owner	Deliverable	Regulatory Link
Implement API gateway security: rate limiting, OAuth scope enforcement, input validation	API / Security	API security configuration audit	PSD2, DORA
Harden SWIFT infrastructure: dedicated network, restricted access, CSP controls	Security / Treasury	SWIFT CSP self-assessment	SWIFT CSP
Deploy tokenization for card data where not already present	Security / Payments	Tokenization coverage report	PCI-DSS
Implement privileged access vaulting for core banking admins	Security	PAM coverage for core banking	DORA, internal audit
Encrypt all backup and archive data with HSM-managed keys	Backup / Security	Encryption coverage report	GDPR, DORA

Phase 3: Sovereignty (Days 60-90) — Banking-Specific Additions

Action	Owner	Deliverable	Regulatory Link
Deploy local AI for fraud detection pilot	AI / Fraud	Fraud detection model with false positive/negative rates	DORA (resilience testing)
Conduct core banking recovery drill	Operations / Security	Recovery time objective (RTO) validation	DORA Article 11
Test TPP disconnection procedure	API / Security	TPP revocation time measurement	PSD2, DORA
Validate incident reporting automation to regulator	Security / Legal	Automated reporting pipeline test	DORA Article 10

Phase 4: Antifragility (Days 90-180) — Banking-Specific Additions

Action	Owner	Deliverable	Regulatory Link
Threat-led penetration testing (TLPT)	External / Security	TLPT report with remediation	DORA Article 11
Chaos engineering on channel layer (non-production)	Resilience	Chaos experiment findings	DORA resilience testing
Red team exercise including TPP exploitation	Security	Red team report with kill chain	DORA, internal audit
Board-level cybersecurity briefing with antifragile metrics	CISO / Board	Quarterly board report	DORA governance, NIS2

---

SWIFT Customer Security Programme (CSP)

For banks using SWIFT messaging:

CSP Control	Antifragile Implementation
1.1: Restrict Internet Access	SWIFT infrastructure on dedicated VLAN with no internet; jump host access only
1.2: Secure the Operating System	Hardened OS baseline, automated patching, application whitelisting
1.3: Restrict Logical Access	Vaulted credentials, MFA, session recording for all SWIFT access
1.4: Malware Protection	EDR on SWIFT workstations, network segmentation, email security
1.5: Software Integrity	Signed software only, integrity monitoring, change control
2.1: Internal Data Flow Security	Encryption for all SWIFT data in transit within the bank
2.2: Security Event Monitoring	Dedicated logging for SWIFT infrastructure; alerting on anomalous access
2.3: Transaction Business Controls	Dual authorization for high-value messages; anomaly detection on message patterns
2.4: Connection Integrity	Mutual TLS, certificate pinning, connection anomaly detection
2.5: Service Providers	Due diligence on SWIFT service bureaus; exit clauses; audit rights
2.6: Customer Environment Security	Annual self-assessment with independent validation
2.7: Penetration Testing	Annual penetration testing of SWIFT infrastructure
2.8: Cyber Incident Information Sharing	Participation in sector ISACs; anonymized threat sharing
2.9: Transaction Controls for Funds Transfers	Additional validation for high-risk corridors and counterparties
2.10: Operational Risk Management	Integration of SWIFT risk into enterprise operational risk framework
2.11: Security Awareness Training	Role-specific training for SWIFT operators and administrators

---

M365 in Banking

Banks often use M365 for corporate functions while maintaining strict separation from payment systems.

Consideration	Banking Requirement
License tier	E3 is common; E5 for security/ compliance officers. Defender for Office 365 P2 strongly recommended for email security.
Data loss prevention	E3 has no native DLP. Critical gap for banks. Recommend Purview or third-party DLP.
Email archiving	7+ year immutable retention for regulatory inquiries. Requires Exchange Online Plan 2 or add-on.
eDiscovery	Legal hold and eDiscovery required for litigation and regulatory requests. Purview required for advanced features.
Customer data in M365	Strictly prohibit customer PII in Teams/SharePoint unless DLP and encryption are active
Third-party apps	Disable user consent; require admin approval for all enterprise apps
Mobile access	Intune-managed devices only; block unmanaged device access to email and SharePoint

See M365 E3 Hardening for tactical guidance, and apply these banking overlays.

---

Core Banking and Legacy System Security

Compensating Controls for Legacy

When core banking systems cannot be modernized directly:

Legacy Limitation	Compensating Control
No native MFA	Place terminal access behind PAM vault with MFA gate; no direct user login
Minimal logging	Deploy screen/session recording for all access; instrument file transfers
No encryption in transit	Force all connectivity through TLS-terminating proxy or VPN
Weak password policies	Vault all service account passwords; rotate automatically; no human knowledge
No patch support	Isolate on dedicated network segment; application whitelisting; intrusion detection
File-based integration	Scan all files at transfer points; validate checksums; log all movements

The Integration Layer as Security Boundary

For banks with legacy core systems, the integration layer (API gateway, ESB, middleware) becomes the security control point:

• All authentication modernized at the integration layer
• All logging enriched at the integration layer
• All rate limiting and circuit breaking enforced at the integration layer
• All input validation performed at the integration layer

The core banking system sees only validated, logged, controlled traffic.

---

Cryptography and Key Management

Banking regulators are increasingly specific about cryptographic controls.

Control	Implementation
Key generation	HSM-generated for all production keys; dual control for key ceremonies
Key storage	HSM or hardware-backed key stores only; no software-only keys for signing or encryption
Key rotation	Automated rotation for TLS keys; annual rotation for long-term signing keys
Quantum readiness	Inventory all cryptographic implementations; begin crypto-agility planning
Key escrow	Split knowledge for backup keys; geographic separation of escrow components

---

Evidence Package for Regulators and Auditors

Regulatory Request	Evidence from Antifragile Program
DORA ICT risk framework	Kill chain analysis, T0 asset register, risk-based vulnerability prioritization
DORA resilience testing	Quarterly recovery drill reports, annual TLPT/penetration test, chaos engineering results
DORA incident reporting	Mean-time-to-detect, mean-time-to-contain, automated reporting pipeline test results
DORA third-party risk	Vendor risk register, exit architectures, contract security clauses
PSD2 SCA compliance	MFA coverage report, dynamic linking validation, TPP access audit
SWIFT CSP	Self-assessment with independent validation, penetration test report
GDPR data protection	Data residency attestation, encryption coverage, DLP policy, breach notification test
Internal audit	Antifragile maturity assessment, control effectiveness metrics, remediation tracking

---

Previous: Vertical: Power Utilities