Threat Detection — SIEM over your own ledger

Every event is decoded, evaluated against a large built-in ruleset plus LedgerFlow-specific rules, and raised as a severity-tiered alert into a dedicated security console.

• Infrastructure & host security — runtime lifecycle events, image and mount activity, host posture checks and system inventory.
• Ledger audit trail — the platform's own tamper-evident audit record (who, which role, which data, before and after) is streamed straight into detection. Credential and role changes, attempts to alter the audit log, and deletions against the ledger escalate as security events, cleanly separated from routine business writes.
• Web-attack detection — edge access logs run through a mature web ruleset flagging injection attempts, cross-site scripting, vulnerability scanners and brute-force or enumeration activity.
• File-integrity & vulnerability — the configuration that defines your security posture — access-control definitions, audit triggers, approval workflow, gateway configuration — is watched for change, with diffs. Known vulnerabilities are detected from a live feed. Data directories and secrets are excluded by design.

The second source is the one competitors cannot easily copy: generic security tooling watches your servers, but has no idea what a suspicious accounting event looks like.

Collecting logs is not security. Every event here is decoded, evaluated against rules, escalated by severity and mapped to recognised frameworks:

• MITRE ATT&CK — alerts carry technique identifiers (account manipulation, log tampering and defence evasion, data destruction), so your coverage lines up with a recognised adversary model rather than an in-house list.
• Regulatory tagging — alerts are tagged for PCI-DSS, GDPR, HIPAA and NIST, so detections double as continuous compliance evidence instead of an annual evidence-gathering scramble.
• Severity-tiered — routine high-volume activity is classified but stays quiet; only the security-relevant subset escalates. Alert fatigue is itself a security failure.

A dedicated security console is the deep-dive tool — alert triage, rule and decoder management, adversary-technique mapping, file-integrity, vulnerability detection and the compliance modules.

The same operational dashboards that surface traces, metrics and logs also receive a read-only view of the security alert stream. An operator sees "under attack?" next to "healthy?" without switching tools — which is exactly the correlation that gets missed when the two live in different products owned by different teams.

Detection is only half the job. Alerts are routed, reviewed and acted on:

• One alerting hub — security alerts and operational alerts share a single notification layer, severity taxonomy and on-call flow. A credential change, an audit-tampering attempt or a ledger deletion pages someone the same way a latency spike does. Channels are configuration, not hard-wiring.
• Low-risk active response — automated containment, such as blocking a brute-forcing or scanning address, is available but off by default and human-in-the-loop. Nothing automated ever touches the ledger, accounts or balances — an automated system that can move money is a bigger risk than the one it defends against.
• Financial-services security dashboard — ledger integrity, authentication failures, separation-of-duties breaches, mass-export attempts and malware, in one pane alongside platform health.
• Scheduled compliance reports — periodic, self-contained per-framework reports generated inside your own deployment.
• Per-host agents & card-data tripwire — optional agents extend integrity and vulnerability scanning to additional hosts. A tripwire alerts the instant a card-shaped value appears anywhere it should not, flagging the match and its location and never the digits themselves.

What the monitoring actually gives you, by framework — coverage, not a control-by-control audit:

• PCI-DSS (reduced scope) — LedgerFlow stores no cardholder card numbers, only tokenized account references, so a deployment sits outside the cardholder-data environment — SAQ A / A-EP territory rather than a full Report on Compliance. That is a materially smaller, cheaper and faster compliance burden than platforms that take custody of card data. The monitoring layer supplies Requirement 10 audit evidence and runs the card-data boundary tripwire.
• SOC 2 / ISO 27001 — the day-to-day fit: continuous logging and monitoring, change detection, and incident detection and response map directly onto the security, availability and change-management criteria.
• GDPR / POPIA — access to and changes against personal and customer data are audited and alertable; security data is self-hosted and retained on a tunable, policy-driven schedule.
• MITRE ATT&CK — detections carry technique identifiers, aligning coverage with a recognised adversary model.
• Tested & retained — each source class and custom rule has a documented test, evidence is kept on a tunable 12-month window with archival to object storage, and triage runbooks ship with the platform.

• Self-hosted — all security data stays inside your deployment. Nothing is shipped to a third party, so your incident data never becomes someone else's breach exposure.
• Tunable retention — how long security and compliance data is kept is a configuration value, with a longer default than operational telemetry. Old data ages out automatically by policy.
• Extensible and standards-based — a documented ruleset you can extend with your own decoders, rules and remote agents for hosts beyond the core platform.

LedgerFlow pairs an immutable double-entry ledger and a tamper-evident audit trail with rule-based detection over that same trail.

So a credential change, an attempt to alter the audit log, a deletion against the ledger, or a scanner probing the API is detected and classified — not merely written down somewhere for someone to find later, after it mattered. Your security posture and compliance evidence become demonstrable from first principles.