EGAF Financial profile: L2 assurance for regulated finance

2026-08-30 · Assurance

The Financial profile is L2. It extends Core and unions the finance-sector frameworks the catalog actually sourced. FFIEC CAT is deliberately absent: the FFIEC stated it would sunset the tool, and citing a withdrawn assessment in a new profile is the research-honesty failure EGAF exists to prevent.

Pre-release, founder-operated system; current capability labels describe the evidence boundary.

How the Evidence-Gated Assurance Framework works

The Evidence-Gated Assurance Framework (EGAF) is a spec-first assurance bar. It is in flight. A project claims conformance to EGAF L1, L2, or L3 at a given commit, with evidence attached. It is not a certification, an accreditation, or an authorization. Independent assessment of any organization remains a separate question.

Three parts make a run:

  1. A control catalog. Each control is either a machine check (an artifact an independent tool produced) or an evidence: attestation (a signed statement by a named principal). A named check with no backing artifact is DRIFT, never PROVEN. An empty-but-parsable file is not a verdict.
  2. A deterministic evaluator. Same inputs produce a byte-identical conformance report. The evaluator does not run tests or scanners. It reads artifacts other tools already produced and records their digests. An agent cannot manufacture PROVEN without producing the artifact the check names.
  3. A committed profile. .egaf/profile.yaml in the consumer repo is what CI evaluates. If that file is absent, the evaluator uses the bundled core profile, so L1 mandatory controls always apply. Profiles may only tighten a threshold; a loosening override is rejected at validation time.

Three levels. L1 Core is mandatory to claim any EGAF conformance: traceability, complexity and duplication caps, whole-codebase statement and branch coverage, mutation on changed files, verifier integrity, signed evidence, supply-chain hygiene. An EXCEPTION never satisfies an L1 control. L2 Regulated adds industry-profile controls (evidence packs, retention, model-risk records). L3 Safety-critical adds independence, structural coverage, tool-qualification inputs, and hazard linkage. Fail one applicable L1 control and the report's first line is L0.

Control status is derived from the seven check outcomes already used in Koinessa evidence bundles:

Check outcome Control status
PASS PROVEN
FAIL FAILED
SKIPPED-NOT-APPLICABLE with a recorded reason NOT-APPLICABLE
INFRASTRUCTURE-ERROR, TOOL-MISSING, EVIDENCE-INVALID, or ABSTAIN DRIFT
Missing evidence DRIFT

A level is achieved only when every applicable control at that level and below is PROVEN or NOT-APPLICABLE (L2/L3 may also count an unexpired EXCEPTION with an independent approver). The report always shows two honesty lists: Not proven (FAILED and DRIFT) and Accepted without proof (NOT-APPLICABLE and EXCEPTION). A clean badge over an empty honesty block is the failure the framework exists to prevent.

Frameworks are guidance. Controls are behavior. Evidence proves the behavior occurred. Organizational burdens — training, physical security, BAAs, a C3PAO assessment, DO-330 tool qualification, a SOC 2 Type II engagement — stay with the organization. The catalog cites clause identifiers and paraphrases; it does not reproduce normative text.

The catalog this series describes is a measured snapshot: 109 controls, vendored into Koinessa at pin 0.0.0-dev+98d08ef on 2026-08-30. The public specification repository is planned; until the operator creates its GitLab group, treat EGAF as a labeled pre-1.0 draft with publication pending. Koinessa's own first mainline conformance report is planned.

Read the Koinessa whitepaper for the surrounding Evidence-Gated Agentic Development thesis, and the verified-delivery report for what this system already publishes about itself.

The Financial profile (id financial, L2)

In flight. Source: vendor/egaf/catalog/profiles/financial.yaml. Extends core.

Added frameworks:

AGT-08 (model risk records and outcomes analysis) is catalogued at L2, so it is already in this profile's active set once level: L2 is declared.

Applicability: agentic, services, data_store, and ui all true. Releases and deploys declared.

Retention is 60 months. That is the longer of two sourced NYDFS floors: 23 NYCRR 500.06(a)(1)/(b) requires not fewer than five years for records able to reconstruct material financial transactions, and 500.06(a)(2) requires not fewer than three years for cybersecurity audit-trail records. PCI DSS v4.0 requirement 10.5.1 requires 12 months with the most recent three months immediately available — a hot-availability tier this single-number field cannot express. GLBA Safeguards Rule 16 CFR 314.4(c)(6) sets a ceiling, not a floor: dispose of customer information within two years of last use. That ceiling conflicts with the NYDFS floor for any record that is also customer information. This profile keeps the longer retention floor because premature disposal of assurance evidence is the worse failure, and names the conflict rather than picking a number silently. An adopter holding customer information in GLBA scope needs a disposal schedule for that narrower record class, separate from this evidence-retention floor.

What the organization must still do: QSA scope, ASV scans, ITGC design, auditor walkthroughs, access reviews, and any supervisory engagement. EGAF maps pipeline evidence onto those regimes. It does not sit the exam.

What this page does not claim

EGAF conformance is a per-commit statement a project makes about itself with evidence attached. It does not confer a certification, a SLSA level, or an authorization to operate. Citing a framework in a profile is a crosswalk, not a state the adopter has reached. Planned items carry no dates.

This article is one of ten in a series. Each page keeps the same mechanics and changes the profile.

The rest of the engineering blog covers the verification loop that EGAF sits on. The Koinessa home page states the product position.