Case Study: Governing a Lending Decision, End to End

Reference scenario · Policy pack: lending_v1 · EVE AI Core production API

A loan officer's AI model returns an approve signal. Before that approval is written into any system of record, EVE intercepts it, evaluates it deterministically against a versioned policy, generates a signed Decision Certificate bound to that policy version, and appends it to a hash-chained audit log. This walkthrough follows that decision from API call to examiner-ready evidence.

The problem

Lenders deploying AI or machine-learning models in the credit-decision pipeline face a concrete evidentiary gap: regulators and examiners expect proof, per decision, of which policy was in effect at the moment the decision was made, what the model produced, and why the action was taken or blocked. ECOA and FCRA adverse-action requirements demand a reasoned basis for each denial or counter-offer. The EU AI Act treats credit-scoring systems as high-risk AI and mandates technical documentation and logging that an authority can inspect after the fact.

The gap is not in what most teams know — it is in what they can prove. Spreadsheet audit logs do not prove that a record was not edited after the fact. Model monitoring dashboards show aggregate drift, not what policy was in force for a specific request at a specific time. A screenshot is not a tamper-evident artifact. When an examiner asks "show me the record for request REQ-20240315-0042 and confirm the policy version that governed it," most AI-in-lending stacks cannot produce that record from a primary source.

EVE is designed to close that gap. The governance layer sits between the model output and the decision commit, produces a signed artifact for every request, and chains those artifacts into an append-only log whose integrity can be verified independently.

The workflow

When a loan officer's system is ready to commit an AI-assisted approval decision, it sends a single call to EVE CoreGuard's evaluation endpoint. The request carries the proposed action, the model's output, and the decision context fields the lender chooses to include. Nothing in that call is trusted until EVE evaluates it.

Request shape

POST /v1/decisions/evaluate
Authorization: Bearer eve_<api-key>
Content-Type: application/json

{
  "request_id":   "req-20240315-0042",
  "timestamp":    "2024-03-15T14:22:07Z",
  "tenant_id":    "org_firstcapital",
  "user": {
    "id":   "u_8821",
    "role": "loan_officer"
  },
  "proposed_action": {
    "type":   "loan_approval",
    "amount": 50000
  },
  "model_output": {
    "decision":    "approve",
    "confidence":  0.91
  },
  "context": {
    "credit_score":          724,
    "debt_to_income":        0.28,
    "employment_verified":   true
  },
  "policy_set": "lending_v1"
}

Response shape

{
  "decision": {
    "status":    "ALLOWED",
    "policy_set": "lending_v1",
    "policy_version": "1.0.3"
  },
  "risk": {
    "level":      "LOW",
    "score":      0.18,
    "factors":    [],
    "violations": []
  },
  "audit": {
    "record_id":         "aud-7f3c2a91",
    "request_id":        "req-20240315-0042",
    "tenant_id":         "org_firstcapital",
    "decision_hash":     "sha256:e3b0c44298fc1c149afb...",
    "certificate_id":    "cert-a9d14c22",
    "chain_position":    1847,
    "prior_chain_hash":  "sha256:4d8b21f097c6e3f...",
    "timestamp":         "2024-03-15T14:22:07.341Z",
    "signature":         "ed25519:base64url(...)"
  }
}

Status values are ALLOWED, BLOCKED, or MODIFIED. A BLOCKED response includes the policy rule that triggered the block and the structured adverse-action rationale that maps to ECOA/FCRA disclosure requirements. A MODIFIED response returns the adjusted action parameters the policy permits (for example, a lower approved amount).

How EVE governed it

Before the lender's system writes any approval record, EVE performs a deterministic pre-execution evaluation. "Deterministic" means the same inputs to the same policy version produce the same output every time — there is no sampling, no prompt temperature, no model inference in the veto path. The lending_v1 policy pack encodes the lender's approved rule set: debt-to-income thresholds, credit-score floors, employment-verification requirements, amount limits by tier, and the adverse-action rationale template required by ECOA.

The evaluation proceeds through three layers:

1. Policy dispatch. The request is routed to the lending_v1 handler. The handler version is recorded in the audit record so the exact rule set is traceable.
2. Rule evaluation. Each policy rule runs against the request context. Any rule violation produces a structured PolicyViolation object with the rule identifier, the field that triggered it, and the human-readable adverse-action reason. HARD_BLOCK rules — those encoding the lender's absolute prohibitions — are never relaxed regardless of the model's confidence score.
3. Risk computation. A risk level (LOW / MEDIUM / HIGH) and a numeric score are computed from the set of violations, their severity weights, and the action's inherent risk class. These propagate to the risk object in the response.

In this scenario, all policy checks cleared: the credit score met the floor, the debt-to-income ratio was below the threshold, and employment was verified. The decision is ALLOWED at LOW risk. Had any rule failed, the response would have been BLOCKED with a structured rationale the lender's disclosure system can consume directly.

The certificate generated

Alongside the disposition, EVE generates a Decision Certificate bound to the specific request, the policy version that evaluated it, and the tenant. In production the certificate is signed with Ed25519; the signing key's public counterpart is published at /.well-known/eve-pubkey and pinned in the Trust Center.

The certificate payload is deterministically canonicalized (RFC 8785 JCS) before signing, which means any party who holds the public key can verify it without contacting EVE. The Evidence Verification page provides a browser-based verifier; the /agent-proof page exposes the interactive offline verification console.

The tamper-proof audit trail

Each Decision Certificate is appended to a per-tenant, hash-chained audit log. The record at position n contains a SHA-256 hash of record n−1. Any insertion, deletion, or edit to a prior record breaks every subsequent hash and is detectable on the next integrity check. The log is structured so that:

• An examiner can request any range of records and verify the chain is unbroken from the first entry in that range to the present tip.
• A deletion — such as a GDPR right-to-erasure request — produces a signed deletion receipt that is itself appended to the chain, preserving audit continuity without retaining the deleted payload.
• Retention is configurable up to seven years to meet financial-records obligations.
• The chain can be exported in full and verified entirely offline using the published public key — EVE does not need to be online for a regulator to replay any decision.

Chain integrity is verifiable on demand via the GET /api/governance/claims/chain/verify endpoint or through the Trust Center dashboard.

Compliance value

The evidence structure EVE produces maps to several regulatory obligations. These are mappings to stated requirements, not legal advice and not a certification of compliance for any specific program.

None of the above constitutes legal advice. Regulated entities should confirm applicability with qualified counsel for their specific jurisdiction and program.

Buyer outcome (illustrative)

The practical value of this architecture is best described in capability terms — what a buyer can now do that they could not do before — rather than in abstract metrics:

• An examiner can replay any decision offline. Given the certificate and the published public key, a regulator can verify the signature, confirm the policy version that governed the request, and see the exact risk assessment — without contacting EVE and without trusting that a log was not retroactively modified.
• Adverse-action documentation is generated at the point of decision. The lender's disclosure system receives a structured rationale object it can consume directly, rather than reconstructing a reason basis from a model's internal weights after the fact.
• Policy changes are versioned and traceable. When the lender updates a threshold in the policy pack, the new version hash is recorded. Every subsequent decision carries that version identifier. An examiner asking "what policy was in effect on March 15?" gets an exact answer, not a reconstruction.
• The audit chain can be handed to a third party for independent verification. The chain export does not require EVE's participation. The verification tool is open and the cryptographic primitives are standard (Ed25519, SHA-256, RFC 8785 canonicalization).
• Deletion does not erase the evidence of governance. If a data-subject deletion request requires removing a record's personal fields, the signed deletion receipt preserves audit continuity without retaining the payload.

Go deeper