Skip to main content
Jira progress: loading…

ESGX-FIN

ESGX for Financial Institutions - Trust & Governance Profile Spec

1. Purpose​

This profile defines how ESGX bindings should work when external access is granted to financial institutions such as banks, lenders, credit platforms, insurers, and financing partners.

It ensures that ESGX-based access is:

  • caller-bound
  • auditable
  • revocable
  • policy-governed
  • suitable for regulated financial decision workflows
  • scalable across multiple pre-qualified institutions

Typical use cases include:

  • annual ESG report retrieval for lending decisions
  • quarterly monitoring for sustainability-linked loans
  • covenant verification
  • taxonomy-alignment evidence retrieval
  • disclosure refresh workflows

2. Core principle​

A bank never gains access merely by possessing an ESGX code. Access requires approved bank identity, valid scoped grant, and active ESGX binding.

So access is based on:

Approved financial institution identity + ESGX code + scoped access grant + policy validity

not on:

ESGX code alone

3. Registry-led financial institution model​

ZAYAZ will maintain a registry of approved financial institutions that are eligible to consume ESGX-based access.

This gives three advantages:

  1. Pre-qualified trust layer

Banks are onboarded once and governed centrally.

  1. Better client UX

Clients can search and select approved banks rather than manually defining each institution.

  1. Reusable access governance

The same financial institution identity can be reused across many clients, ESGX bindings, and grant records.

4. Architecture​

The financial-institution ESGX model should consist of four layers:

Layer 1 — Approved Financial Institution Registry

Stores banks and other approved institutions that may receive ESGX-based access.

Layer 2 — Shared ESGX Binding

Stores the governed execution handle and semantic binding.

Layer 3 — Scoped Access Grant

Stores which approved institutions may use which ESGX bindings, for what purpose, and during what period.

Layer 4 — Runtime Auth + ZSSR Enforcement

Ensures actual execution only occurs when:

  • the caller is authenticated
  • the institution is approved
  • the grant is active
  • the ESGX binding is active
  • ZSSR permits execution

5. Bank access model​

Preferred model

Shared ESGX binding + allowed caller list + scoped access grant

This means:

  • the client generates one ESGX binding for a use case
  • the client selects one or more approved banks from the ZAYAZ institution registry
  • ZAYAZ creates scoped access grants for those institutions
  • the client can turn access on or off per institution without changing the ESGX itself

This allows easier ESGX generation for a client in e.g. an interest rate negotiation situation wher many banks may be apporached.

6. Financial institution registry​

ZAYAZ maintain a registry of approved financial institutions that can consume ESGX codes.

Each registered institution should have:

  • institution identifier (e.g. FIN-196-123-456-789)
  • legal name
  • display name
  • country/jurisdiction
  • organization type
  • auth profile
  • trust level
  • onboarding status
  • lifecycle status
  • contact / admin metadata
  • optional integration profile metadata

This registry acts as the pre-qualified trust source for bank access grants.

7. Shared ESGX binding model​

In the shared model, the ESGX binding itself represents the governed execution handle, but it does not directly enumerate all active callers inside the binding row.

Instead:

  • the ESGX binding defines the semantic execution profile
  • scoped grants define who may use it

This keeps the ESGX binding stable even when access grants change.

8. Scoped access grant model​

ZAYAZ issue a scoped access grant between:

  • an ESGX binding
  • an approved financial institution
  • an allowed purpose
  • a validity window
  • optional additional policy controls

This means a bank can only use an ESGX if:

  1. the bank is registered and approved
  2. the bank authenticates successfully
  3. the ESGX binding is active
  4. the scoped access grant is active
  5. the request satisfies policy and ZSSR checks

9. Why this is stronger than e.g. embedding bank identity into ESGX​

This model is better because it separates:

ESGX binding

What the execution handle means

Institution registry

Who the approved bank is

Scoped grant

Who is currently allowed to use that ESGX

That separation makes the system:

  • more scalable
  • more revocable
  • easier to audit
  • easier to rotate credentials
  • easier for clients to manage

10. Client experience model​

The client workflow is as follows:

  1. Generate ESGX binding
  2. Search approved financial institutions in ZAYAZ registry
  3. Select one or more institutions
  4. Enable/disable access per institution
  5. Optionally define:
  • purpose
  • validity window
  • access mode
  • response restrictions
  1. Share the ESGX code with the selected bank(s)

The bank then uses:

  • its normal bank credential
  • the ESGX code

ZAYAZ resolves the rest.

11. Trust model​

A financial ESGX invocation should be treated as:

governed execution of an external alias under institution-bound access control

This means every invocation should validate:

  • caller authentication
  • institution registration status
  • scoped grant status
  • ESGX binding lifecycle
  • permitted use
  • validity window
  • ZSSR policy
  • artifact and opcode compatibility

12. Required controls​

12.1. Institution registry required​

Bank-grade ESGX access should only be granted to institutions registered in the approved financial institution registry.

12.2. Scoped grant required​

A valid scoped access grant must exist between the institution and the ESGX binding.

12.3. Caller identity required​

The caller must authenticate using the approved auth profile associated with the institution.

12.4. Validity window required​

Both ESGX binding and grant should support:

  • valid_from
  • valid_to

12.5. Revocation required​

Clients or ZAYAZ administrators must be able to disable access for a specific institution without deleting the ESGX binding.

12.6. ZSSR mandatory​

All financial-institution ESGX executions must route through ZSSR.

12.7. Audit logging mandatory​

Every invocation must log:

  • institution id
  • caller org
  • client/data owner
  • ESGX code
  • resolved opcode
  • scoped grant id
  • timestamp
  • result status
  • execution id

13. Purpose-bound access​

Financial ESGX grants should ideally include a permitted-use context.

Examples:

  • loan_origination
  • covenant_monitoring
  • sustainability_linked_margin_review
  • assurance_support

This is useful for:

  • policy
  • audit
  • analytics
  • legal defensibility

The purpose should sit primarily on the access grant, not necessarily inside the ESGX binding itself.

14. Data access modes​

14.1. Snapshot access​

Used for immutable historical artifacts.

Examples:

  • last year’s ESG report
  • approved annual disclosure package

Characteristics:

  • stable artifact reference
  • often long-lived
  • suitable for underwriting

14.2. Rolling access​

Used for dynamic or latest-state retrieval.

Examples:

  • latest quarterly report
  • latest covenant evidence set

Characteristics:

  • resolves latest approved matching artifact
  • shorter validity preferred
  • suitable for ongoing monitoring

The access mode may be declared on the ESGX binding and further constrained on the access grant.

15. Shared model​

Shared ESGX binding + approved financial institution registry + scoped access grant

The shared model allowes:

  • multiple banks need equivalent access
  • client UX simplicity matters
  • central institution governance is available

16. Resolution rules for bank-grade ESGX​

When a bank calls with:

  • authenticated bank credential
  • ESGX code

the resolver must check in this order:

  1. ESGX exists
  2. ESGX is active
  3. institution is registered and active
  4. caller auth profile matches registered institution
  5. scoped access grant exists
  6. grant is active
  7. validity window is open
  8. permitted use is allowed
  9. underlying opcode is active
  10. artifact resolution succeeds
  11. ZSSR policy allows execution

If any step fails:

  • deny access
  • log denial
  • return controlled error

17. Example bank flow​

Shared annual report ESGX

Client generates:

ESGX_h82k1a9q_0910

Meaning:

  • annual ESG report snapshot
  • governed export/retrieval profile
  • may be shared with one or more approved institutions through grants

Client then enables:

  • NordBank
  • GreenBank

Each enablement creates its own scoped access grant.

Shared quarterly monitoring ESGX

Client generates:

ESGX_r71nv4kp_1410

Meaning:

  • latest quarterly report rolling pull
  • can be granted to multiple approved financial institutions

Client turns on:

  • NordBank = active
  • GreenBank = inactive
  • CapitalTrust = active

Bank invocation

NordBank sends:

  • authenticated bank credential
  • ESGX code

Resolver checks:

  • NordBank is approved
  • grant exists for NordBank and this ESGX
  • use policy valid
  • execution allowed

Then routes through ZSSR.

For financial institutions:

Require

  • approved institution registry membership
  • authenticated caller identity
  • scoped grant
  • validity window
  • revocation
  • audit logging
  • ZSSR enforcement

Prefer

  • purpose binding
  • snapshot vs rolling distinction
  • response minimization
  • trust threshold
  • signed evidence metadata where relevant

19. What not to do​

Do not:

  • rely on ESGX code alone as proof of access
  • embed raw bank credentials in ESGX
  • let ESGX bypass ZSSR
  • use shared access without institution-specific grants
  • treat ESGX as an unmanaged bearer secret
  1. Policy statement

For financial institution use cases, ESGX access should be based on a registered approved institution, an active shared ESGX binding, and an active scoped access grant. Access must remain caller-bound, time-bounded, auditable, revocable, and resolved through ZSSR against canonical core opcode semantics.



GitHub RepoRequest for Change (RFC)