They should prioritise orchestration whenever customer demographics, transaction risk, or regulatory obligations require more than one acceptable method. Wallet support is useful, but it is not a universal replacement. The better design choice is to manage identity assurance through a governed routing layer.
Why orchestration becomes the better decision when wallets are not enough
Wallet-only deployment is attractive when the goal is simple enablement, but banks rarely operate in a simple trust environment. Orchestration becomes the stronger pattern when one channel, one proofing method, or one wallet ecosystem cannot satisfy the bank’s mix of customer segments, fraud exposure, and policy obligations. The real design question is whether the bank needs governed choice, not just digital convenience.
That distinction matters because a wallet is usually one input into identity assurance, not the entire assurance model. Banks often need to vary the method based on customer risk, product sensitivity, and local regulatory expectations. A routing layer lets the institution decide which method is acceptable for which scenario, instead of forcing every customer into the same assurance path.
For banks, orchestration also reduces design brittleness. If a wallet provider, device capability, or market rollout changes, the bank can reroute assurance without redesigning the whole customer journey. That makes orchestration the more durable control plane when identity decisions must survive product expansion, channel diversity, and changing regulatory treatment across segments or jurisdictions.
Where wallet-only deployment usually breaks down
Wallet-only design tends to fail when it assumes homogeneous customers and uniform acceptance. In practice, some users will have compatible wallets and strong device access, while others will need alternative methods because of device limitations, accessibility needs, fraud policy, or local legal rules. A single wallet path can become an unnecessary exclusion point.
It also becomes weak when the bank needs to distinguish between low-friction access and higher-assurance transactions. A wallet can support one class of interaction, but it may not be sufficient for step-up verification, account recovery, delegated access, or higher-risk approvals. Those cases need a policy engine that can choose among acceptable methods rather than hard-code one favourite method.
That is why wallet support should be treated as an available credentialing option, not the architecture itself. The bank still has to govern which identity proofing source, authentication method, or transaction challenge is acceptable for each use case. Orchestration preserves that judgment.
Why orchestration is the governance layer banks actually need
Orchestration is valuable because it separates policy from presentation. The bank can define the routing rules once, then choose wallet, biometrics, federated identity, document-based proofing, or other approved methods according to customer type and transaction context. That makes the authentication design auditable rather than ad hoc.
It also helps banks maintain consistency across distribution channels. A branch flow, mobile flow, call-centre flow, and partner flow should not all be forced into the same mechanism if the risks differ. Orchestration allows the bank to keep the assurance standard stable while changing the method underneath it.
In practice, this is the point at which the bank stops asking, "Which wallet should we support?" and starts asking, "How do we govern identity assurance across all acceptable methods?" If the answer must vary by demographic, transaction risk, or regulatory obligation, the routing layer is not optional, it is the control surface. Multi-Agent and A2A Security Guide
Risk and Threat Considerations
Wallet-only deployment can create concentration risk, because a single acceptance path can become the only practical route for a whole customer segment. That increases the chance of exclusion, operational dependency, and policy failure when the wallet ecosystem does not align with the bank’s risk model or regulatory duties.
Failure mechanism: The bank hard-codes one wallet path as the default trust decision, then loses the ability to step up, divert, or substitute methods when risk, accessibility, or jurisdictional requirements change.
Impact: Customers may be blocked from legitimate access, weaker assurance may be used where stronger control is needed, or the bank may be forced into exception handling that is hard to monitor and audit.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Banks are authenticating external customers through selectable identity methods. |
| IA-12 — Identity Proofing | Orchestration depends on choosing proofing methods appropriate to customer and regulatory context. | |
| IA-5 — Authenticator Management | Wallets are one authenticator option, so lifecycle governance remains central. | |
| Recommendation — Use IA-8 to govern customer authentication choices across all approved access paths. Apply IA-12 to ensure proofing strength matches the customer risk case. Manage authenticator issuance, replacement, and revocation under IA-5. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The routing layer is an access-control decision point for acceptable login methods. |
| A.5.16 — Identity management | Orchestration governs how identities are recognised and routed across methods. | |
| A.8.5 — Secure authentication | The topic is about selecting authentication methods that fit assurance needs. | |
| Recommendation — Define and enforce access-control rules for each accepted identity path. Standardise identity-management rules across wallet and non-wallet paths. Require secure authentication controls for every approved customer journey. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | The answer concerns governing multiple acceptable authentication methods. |
| GV.OC-01 — Organizational Context | Banks must choose identity methods based on customer segments and obligations. | |
| GV.RM-01 — Risk Management Strategy | The decision is driven by transaction risk and acceptable assurance variance. | |
| Recommendation — Align authentication and access control to the bank’s routed assurance policy. Tie identity orchestration decisions to business context and regulatory scope. Set routing rules according to the institution’s risk appetite and transaction risk. | ||
Practitioner Guidance
What to prioritise: Define the policy decision first, then map wallet support into it. If the same customer journey must handle low-risk access, high-risk transactions, and recovery scenarios, orchestration should be the default architecture choice.
What to verify: Confirm that the routing layer can express different acceptance rules for different customer populations and transaction classes, and that those rules are reviewable by risk and compliance teams. A wallet feature is not enough if the bank cannot prove why one method was chosen over another.
What good looks like: The bank can accept multiple assurance methods, apply them consistently, and change the routing logic without replatforming the whole identity flow. The strongest design is the one that preserves choice without losing control. CSA MAESTRO agentic AI threat modeling framework OWASP Agentic AI Top 10
Practitioner takeaway: Wallets are a channel capability, orchestration is the assurance strategy, and banks should choose the latter whenever identity risk cannot be safely solved with one fixed method.
Related resources from NHI Mgmt Group
- How should security teams prioritise NHI remediation in cloud environments?
- Should organisations prioritise external exposure or internal credential governance first?
- When should teams prioritise orchestration over adding more auth features?
- When should banks prioritise continuous SBOM lifecycle control over manual review?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org