SBV Circular 83: Having an Authority Matrix Is Not the Same as Enforcing Decision Authority

Banks do not normally lack authority rules.

Approval limits, delegation matrices, job responsibilities and escalation requirements are already part of banking operations.

Circular 83/2025/TT-NHNN reinforces this under Article 5. It requires delegation of decision-making authority and refers to transaction size, complexity, risk limits and other criteria.

The more practical question is not whether these rules exist.

When an actual decision is made, can the bank show that the authority conditions it defined were actually followed?

A policy may require a higher level of authority for a particular decision. A user may still have access to the system. A workflow may still allow the matter to move forward. An exception may arise after the process has started.

The authority matrix can remain correct.

The question is whether the decision followed it.

1. Start with what Circular 83 actually requires

Article 5(1)(b) addresses delegation of decision-making authority. It links delegation to the reliability of the competent level and the capability of the individual or unit performing the task.

The same provision says decision authority is to be expressed through criteria including transaction size, complexity, risk limits, other limits and other criteria under the bank's internal regulations.

Circular 83 does not prescribe a particular authority matrix, workflow or technology. The bank determines its internal delegation arrangements.

This paper therefore does not ask how the bank should design its authority rules. It asks what happens when those rules meet an actual decision.

2. System access is not the same as decision authority

In practice, system access and decision authority can be confused.

A user may have permission to open a case, enter findings, change a status or click an approval button. Those permissions are necessary for the system to operate.

But permission to perform a system action does not necessarily mean the person has authority to make every decision that the action can represent.

For example, an employee may legitimately have access to an approval function because it is required for the role. The bank's policy may nevertheless restrict certain decisions according to amount, risk, complexity, product, exception type or another condition.

The system can therefore accept the action while the decision itself falls outside the authority conditions established by the bank.

The control question is not simply: Could the user perform the action?

It is: Was the user permitted to exercise this decision authority under the conditions that applied at that time?

3. An approval limit is only one authority condition

Authority is often easiest to see when it is expressed as a monetary limit.

A transaction below a defined amount can be approved at one level. A larger transaction requires a higher level.

Article 5 is broader. It also refers to complexity, risk limits and other criteria.

This matters because two decisions can have the same monetary value but require different authority under the bank's internal rules.

One may be routine. The other may involve a policy exception, a higher risk classification, an unusual structure or another condition requiring escalation or additional approval.

The authority matrix may therefore be correct while the applicable authority changes according to the characteristics of the decision.

4. The difficult point is when policy has to become action

An authority rule written in a policy is static. An operational decision is not.

A matter can begin within normal conditions and later encounter an exception. New information can change its risk. A threshold can be crossed. A second approval can become necessary.

At that point, the bank's authority rule has to become an operational control.

There are several ways this can happen. A person may recognise the condition and escalate it. A workflow may route the matter to another approver. A system rule may stop the action until additional approval is obtained.

The method is less important than the outcome: the decision should proceed according to the authority conditions the bank has established.

If it does not, the existence of a correct authority matrix by itself does not prevent the authority breach.

5. Workflow can route a decision without governing its authority

Workflow is useful for moving work from one step or person to another.

It can also enforce authority where the relevant authority rules have been built into the workflow.

But the two functions should not automatically be treated as the same thing.

A workflow may correctly send a matter to the next configured step even when an authority condition exists elsewhere in policy, another system or a separate approval matrix.

Likewise, a workflow may require Supervisor Approval without establishing whether this particular supervisor satisfies the authority condition applicable to the decision.

The important question is therefore not whether the workflow operated as designed. It is whether the decision path conformed to the bank's applicable authority rules.

6. Exceptions expose the problem

Normal decisions are usually the easiest to govern because the expected path is known.

Exceptions are more revealing.

Suppose a matter normally falls within an officer's authority. During review, a policy exception is identified. The bank's rules require the exception to be approved by a higher authority.

Several things are now relevant: Was the exception recognised? Did the original authority cease to be sufficient for the action concerned? Was the required higher authority obtained? Did the decision proceed only after that condition was satisfied?

A completed workflow can show that the process reached an outcome.

An authority record should be able to show that the outcome was reached under the authority conditions the bank required.

7. A decision-authority test

A bank can test this using decisions that have already been completed.

For each sampled decision, it could ask:

1. What decision was actually made?
2. What internal authority rule applied to that decision?
3. Which conditions determined the required authority?
4. Who exercised the authority?
5. Did that person or function satisfy the applicable authority conditions at that time?
6. Did any exception, threshold or change require additional approval or escalation?
7. If so, was that authority obtained before the decision proceeded?
8. Can the bank produce the evidence without relying mainly on memory or manual reconstruction?

This is not a compliance test prescribed by Circular 83. It is a practical way to examine whether bank-defined authority rules were reflected in actual decisions.

8. What Circular 83 does not require

Circular 83 does not expressly require real-time authority validation for every banking decision.

It does not require a central decision-governance platform, a particular workflow architecture or one repository containing every authority record.

It also does not say that every authority condition must be automated.

A bank may operate effective controls through existing systems, procedures and human review.

The regulatory requirement belongs to the bank's internal-control and delegation framework. Technology can support that framework, but it does not define the bank's authority.

9. Automation makes the distinction more important

As banking processes become more automated, it can become easier to prove that a system action occurred.

Logs can show who clicked Approve. Workflows can show which step completed. Access-control records can show that the user had permission to use the function.

Those records are valuable, but they do not always answer the authority question.

An AI recommendation creates the same distinction. The authorised human may remain responsible for the final decision, but the bank still needs its own rules to determine who is permitted to accept, override, escalate or approve the resulting action.

Automation therefore does not remove decision authority. It makes the difference between system permission and governance authority more important to understand.

10. The question worth asking

Banks already have authority matrices.

The harder question is whether those matrices remain visible in the decisions that people and systems actually make.

That suggests two different questions.

Definition: Have we established who is allowed to decide, and under what conditions?

Execution: Can we show that the actual decision followed those conditions?

Circular 83 clearly requires banks to establish delegation of decision-making authority. It does not prescribe a general mechanism for validating every decision against that authority at the moment it is made.

For banks, that leaves a practical control question:

When policy says who may decide, how does the bank make sure the decision actually follows it?

Research note

This paper discusses selected operational implications of Circular 83/2025/TT-NHNN. It is not legal advice.

References in this paper to decision-authority enforcement, authority validation and the decision-authority test are Blitz Research interpretations. They are not terms presented as explicit requirements of Circular 83.

Banks should assess the official Vietnamese text of Circular 83 against their own delegation arrangements, internal policies, systems and regulatory obligations.

Primary references

State Bank of Vietnam, Circular 83/2025/TT-NHNN, issued 31 December 2025, effective 1 July 2026.

Article 5(1)(b) — delegation of decision-making authority, including capability of the individual/unit and criteria such as transaction size, complexity and risk limits.

Article 5(1)(c) — assignment of functions and duties, segregation of duties, independent checking and controls relating to conflicts and internal-rule violations.

Official Vietnamese legal text should be treated as the controlling reference.