Beyond Identity: A Contextual Authorization Model for Banking

Authorization as Relationships Between Business Objects

Traditional authorization models are largely built around identities. A user authenticates, one or more roles are assigned, and permissions are evaluated to determine whether an operation can be performed. This approach has proven effective for controlling access to applications, but it becomes increasingly difficult to express complex banking policies where authorization depends not only on who is performing an action, but also on the relationships between many business entities participating in the operation.

This paper proposes a different perspective. Instead of viewing authorization as permissions granted to identities, we describe authorization as the validation that every business object involved in an operation is allowed to play a specific role within a particular business context.

Under this model, customers, accounts, contracts, products, channels, applications, APIs, AI agents and even business activities become first-class participants in authorization decisions. Policies are expressed using business concepts rather than technical identities, making them easier to understand, govern and evolve.

1. Introduction

Modern banks execute millions of business operations every day. A simple payment may involve customers, accounts, products, channels, legal entities, currencies, limits, contracts, applications, fraud engines and regulatory controls.

Yet most authorization systems still attempt to answer a surprisingly simple question:

Can this user perform this operation?

While appropriate decades ago, this question no longer reflects how banking systems actually operate.

Today’s banking platforms include not only employees and customers, but also automated services, APIs, batch processes, mobile applications and increasingly AI agents acting autonomously on behalf of customers or financial institutions.

In this environment, identity alone becomes an insufficient foundation for authorization.

The real question is no longer who is requesting an operation.

It is:

Is every participant involved in this business operation authorized to play the role it assumes within this specific business context?

2. The Limits of Identity-Centric Authorization

Traditional authorization follows a straightforward model.

Identity → Role → Permission

• A user authenticates.
• The system determines the user’s roles.
• Permissions associated with those roles determine whether access is granted.

This model implicitly assumes that authorization depends almost exclusively on the identity performing the action. But banking operations rarely behave this way.

Consider a corporate payment. Authorization depends on questions such as:

• Is the requester a legal representative of the company?
• Is the account allowed to act as the debiting account?
• Can this payment type use this currency?
• Is the beneficiary eligible to receive the transfer?
• Is this channel allowed for this operation?
• Does the transaction amount exceed regulatory thresholds?
• Is the customer’s KYC status valid?

Notice that most of these questions are not about the requester. They concern other business objects participating in the transaction.

Authorization therefore becomes the validation of an entire business configuration rather than a single identity.

3. Business Operations as Contexts

Every banking operation creates a temporary business context.

A payment, for example, brings together multiple business objects:

• the customer requesting the payment
• the debiting account
• the crediting account
• the payment activity
• the channel
• the amount
• the currency
• the execution date
• the beneficiary

Each of these objects participates in the operation for a specific purpose. The context defines how these objects relate to one another. Without the context, the relationships between the objects have no meaning.

• An account is simply an account, but within a payment, however, it becomes the debiting account.
• A customer is simply a customer, but within the execution of the payment, the same customer becomes the requester.

Authorization therefore should not evaluate isolated objects. It should evaluate objects participating within a business context.

4. Objects Play Roles

One of the most important observations is that business objects are stable, while their roles are contextual.

A customer remains the same customer throughout the bank.

However, depending on the context, that customer may simultaneously act as:

• Account Holder
• Requester
• Beneficiary
• Guarantor
• Legal Representative
• Borrower

Similarly, an account may play different roles:

• Debiting Account
• Crediting Account
• Settlement Account
• Collateral Account

The object itself never changes and only the role changes.

This distinction is fundamental because authorization is rarely attached to the object itself. It is attached to the role the object is attempting to perform within a particular context.

objects and roles

5. Authorization as Relationship Validation

This leads to a different way of expressing authorization policies.

Traditional policies are often written as permissions assigned to users.

For example:

A Payment Operator may execute national payments.

Although technically correct, this statement hides the business relationships that actually determine whether the payment is valid.

A contextual model allows policies to be written using business concepts.

For example:

Account holders may request national payments using their accounts as debiting accounts.

Or:

A customer may play the requester role only if its KYC status is valid.

Or:

An account may play the debiting account role only if it belongs to the requesting customer.

These policies no longer describe technical permissions; they describe business rules. The authorization engine simply verifies that every object involved in the operation is allowed to assume the required role.

6. A Business Object Ontology

To express authorization consistently, the bank requires a common vocabulary describing its business objects.

This object model — or ontology — defines:

• business objects
• relationships
• roles
• attributes
• classifications
• hierarchies

Example of hierarchies:

• A National Payment is a type of Payment.
• A Payment is a Financial Transaction.
• A Financial Transaction is a Business Activity.

Similarly, examples of classification

• Accounts for residence is a classification of Account.
• VIP Customer is a classification of Customer.

Because these relationships are explicitly modeled, authorization policies can be defined at different levels of abstraction

• A policy applying to all financial transactions is automatically inherited by every payment type.
• A policy applying to business accounts automatically applies to all specialized account types.
• The ontology therefore becomes the semantic foundation of authorization.

7. Authorization Beyond Human Users

An important consequence of this model is that authorization naturally extends beyond people.

Any business object can participate in authorization.

This includes:

• APIs
• applications
• automated processes
• AI agents
• devices
• integration services
• external partners

Each is simply another object capable of playing one or more roles within a business context.

The authorization model remains unchanged regardless of whether the requester is a human employee, a mobile application or an autonomous AI assistant.

8. Benefits

Viewing authorization as relationship validation provides several advantages.

First, policies are expressed using business language rather than technical constructs, making them understandable by both business and technology teams.

Second, authorization becomes independent of individual applications, allowing the same policies to be consistently enforced across channels and systems.

Third, the model naturally supports increasingly complex banking ecosystems, including APIs, cloud-native architectures and AI-driven services.

Finally, business policies become reusable because they describe stable business concepts instead of implementation-specific identities or application roles.

9. Conclusion

Identity remains essential for authentication. However, authentication answers only one question:

Who is requesting the operation?

Banking authorization requires answering a different question:

Is every business object involved in this operation allowed to play the role it assumes within this business context?

By shifting authorization from identities to business relationships, banks can express policies in the language of their business rather than the language of their technology.

The result is a model that is easier to govern, easier to evolve, and better aligned with the increasingly interconnected and automated nature of modern banking systems.