Identity is not ownership: a stronger model for financial access
A signed-in person is not automatically a financial customer. A valid OAuth grant is not account ownership. And a technical user that can call a banking system is not the person whose money is being accessed.
Ireti Platform keeps these facts separate and grants access only when the required relationships intersect for the requested operation.
Five concepts that must remain distinct
| Concept | What it establishes | What it does not establish |
|---|---|---|
| Human identity | The person authenticated by an identity authority | A financial customer, account owner, or financial permission |
| Application identity | The OAuth client asking to act | The human's identity or unrestricted access |
| Operational identity | A Fineract AppUser or service identity that can execute an operation | That the identity is the customer or owns an account |
| Financial party | A customer, organization, or other party in the financial system | A login session or application grant |
| Account relationship | The capacity in which a party relates to an account | Permission for every application and operation |
A person may be a sole owner, joint owner, authorized operator, guardian,
organization representative, read-only delegate, or beneficiary. Those
relationships have different meanings and should not be reduced to a permanent
Boolean owns field.
The two relationships behind owner-specific access
Owner-specific access requires two independently established business facts:
(identity issuer, human subject) -> financial party
financial party -> account relationship
The first answers which financial party an authenticated person represents. The second answers how that party relates to a particular account.
Only their composition can support an account-level decision. Email addresses, names, phone numbers, and usernames can help locate candidate records, but mutable attributes are not proof that two records represent the same person.
An identity-to-party binding should be explicit and auditable. It should retain the identity issuer and subject, financial-party identifier, tenant context, verification method, provenance, approving actor, effective dates, revocation, and dispute status.
The financial system remains authoritative for the second relationship. It owns its customers, accounts, and the business meaning of their relationships. The control plane must not create a competing copy of financial ownership.
Consent is another boundary
OAuth consent answers whether a particular application may act in a bounded way for a signed-in person. It does not establish that the person owns an account.
Conversely, owning an account does not authorize every application to read it, initiate a payment, or perform an administrative operation. Effective delegated authority is the intersection of:
- an authenticated human;
- an identified OAuth client;
- the client's approved delegated capability;
- the person's current consent;
- an active identity-to-financial-party binding;
- the party's current account relationship; and
- the financial policy for the requested operation.
Every factor narrows access. No factor substitutes for another.
This separation also enables precise revocation. An administrator can suspend an identity binding without altering ownership. A customer can disconnect one application without losing an account. A financial relationship can end without deleting the person's identity. A technical credential can rotate without changing any business relationship.
What Plaid, Chase, and Mambu confirm
Established financial platforms use different terminology, but their public models reinforce important parts of this separation.
Plaid: a connection is not the underlying relationship
Plaid models an Item as a connection to a financial institution. One Item can contain multiple accounts, and its access token authorizes server-side access to that connection. Plaid supports both Item-level and account-level permission-revocation events.
Plaid Identity retrieves owner information reported by the institution. Identity Match compares known identity attributes with information on file at that institution. Plaid describes Identity Verification and Identity as complementary: one verifies the person for KYC purposes, while the other helps determine whether institution-reported account information matches that identity.
That is useful evidence, but the connection should not become a universal ownership record. For accounts held within our financial system, the financial system remains authoritative. For externally held accounts, Plaid can provide a governed connection and verification evidence without becoming the source of the underlying relationship.
Chase: the institution establishes eligibility
Chase's Data Security Center lets customers inspect connected applications, understand what information is shared, adjust access duration, select eligible accounts, manage permissions, and unlink an application.
The important pattern is that account eligibility comes from the financial institution. An application does not nominate an arbitrary account and declare that it belongs to the person. The customer chooses among accounts the institution already considers eligible, and that sharing decision remains manageable over time.
Mambu: operational users are not financial customers
Mambu distinguishes clients and groups that require financial products from the users and API consumers authorized to operate its software and APIs. This reinforces a foundational rule for Fineract integrations:
Fineract AppUser != Fineract customer
An operational or service identity may execute a request. It does not thereby become the customer, acquire ownership, or replace the customer's relationship to an account.
The Ireti direction
Ireti combines those lessons without adopting any vendor's model as its architecture:
Ireti Identity authenticates the human
|
v
A verified binding resolves the financial party
|
v
The financial system resolves current account relationships
|
v
Ireti Platform resolves application permission and consent
|
v
The gateway composes both current decisions
|
v
A controlled technical identity executes the operation
Ireti Identity owns authentication and stable identity context. Ireti Platform owns organization and workspace access, application registration, delegated capabilities, consent, and its bounded authorization decision. Fineract owns financial parties, accounts, financial relationships, transaction rules, and product-local enforcement.
The gateway preserves the human, application, financial party, account, requested operation, decision, and correlation identifier while using a controlled technical identity. Technical ability is never treated as business authority.
The experience this enables
Institutional administrators can establish and verify identity-to-party bindings, inspect provenance, resolve collisions, review financial relationships, suspend bindings independently, and audit every mutation.
Customers can see accounts for which the financial system confirms an eligible relationship, select which applications may access them, understand requested capabilities and duration, review connected applications, and revoke one account, one capability, or an entire connection.
This is more than a user-management screen. It is a financial identity and relationship system that supports individual, joint, institutional, delegated, and future relationship models without weakening authorization.
Why the model is stronger
Ireti's model does not confuse authentication with customer identity. It does not treat OAuth consent as ownership. It does not make an operational user the financial party. It does not let an application nominate arbitrary accounts. It does not hide the human behind a service credential. And it does not make revocation depend on waiting for an old token to expire.
That rigor creates a stronger foundation for open finance: identity, relationships, consent, and execution remain independently governed, independently auditable, and independently revocable.