By NHI Mgmt Group Editorial TeamPublished 2025-08-15Domain: Governance & RiskSource: Raidiam

TL;DR: New Zealand rolled out a national Confirmation of Payee scheme to cover more than 95% of consumer bank accounts in six months and twelve days, with banks connecting through a central trust framework, according to Raidiam. The result shows how shared identity and verification infrastructure can cut fraud risk, reduce friction, and support future API-based services.


At a glance

What this is: This is a case study on New Zealand’s national Confirmation of Payee rollout and its central trust framework for bank-to-bank verification.

Why it matters: It matters because identity and access teams should treat payment verification, trust frameworks, and ecosystem governance as reusable controls, not one-off banking features.

By the numbers:

👉 Read Raidiam's case study on New Zealand's confirmation of payee rollout


Context

Confirmation of Payee is a payment verification control that checks whether a payee name matches the destination account before money is sent. In practice, it reduces mistaken payments and helps disrupt fraud patterns that rely on account detail manipulation, which is why the underlying trust model matters as much as the customer-facing check.

New Zealand’s rollout is relevant to IAM practitioners because it shows how secure identity-style verification can be delivered through a shared ecosystem rather than duplicated inside every organisation. The lesson is not limited to banking: when trust is centralised, the governance model becomes the control surface.

For identity teams, the interesting part is not only the payment use case but the operating model behind it. A bank-owned rules and standards body, a central trust platform, and API-based onboarding together created a pattern that looks familiar to anyone managing federated identity, workload trust, or shared access infrastructure.


Key questions

Q: How should organisations design shared verification controls across multiple institutions?

A: They should define a common trust framework, standardise the verification API, and keep sensitive records under local ownership. The shared layer should coordinate assurance and response rules, while each participant remains responsible for its own data and entitlements. That approach reduces duplication and makes the control reusable across additional services.

Q: Why do ecosystem trust models matter for IAM and identity governance?

A: They matter because they move verification from isolated systems into a shared governance layer. That reduces inconsistent control design, supports federation, and makes it easier to extend the same trust pattern to new services without rebuilding each participant’s access model from scratch.

Q: What do security teams get wrong about payment verification controls?

A: They often treat them as customer experience features rather than governance controls. In reality, the match logic, data ownership model, and exception handling all shape whether the control actually reduces fraud, prevents mistaken transfers, and scales to future ecosystem use cases.

Q: How do you know if a trust framework is actually working?

A: You should look for consistent onboarding, low-friction participant integration, and clear decision outcomes at the point of action. If banks or partners still need bespoke logic for each connection, the trust model is not really reusable and the governance burden has merely shifted elsewhere.


Technical breakdown

Central trust frameworks for inter-organisational verification

A central trust framework provides the rules, assurance, and technical rails that let independent parties verify each other without exposing their internal systems. In this model, the bank keeps sensitive data inside its own environment while the shared platform coordinates standards-based requests and responses. That separation matters because it reduces duplicated control design while preserving local ownership of records. For practitioners, the architectural question is whether trust can be enforced at the ecosystem boundary rather than rebuilt in every participant environment.

Practical implication: design verification controls so the trust decision is shared, but the underlying identity data stays under local control.

API-based onboarding and ecosystem extensibility

The article describes a model where banks connect through APIs and make minor digital journey changes instead of rebuilding their core systems. That pattern is important because it turns onboarding into a repeatable integration problem rather than a bespoke programme for each participant. Once the trust layer exists, the same architecture can support additional services such as anti-scam checks or broader data-sharing functions. For identity programmes, this is a reminder that governance models need to scale with the integration layer, not just with the original use case.

Practical implication: standardise onboarding contracts and control checks so future services can reuse the same trust rails.

Match, partial match, and no match outcomes

Confirmation of Payee works by comparing entered payee details against the recipient bank’s records and returning a match, partial match, or no match outcome. That tri-state result is useful because it gives the customer a decision signal without exposing unnecessary account data. It also shows how identity verification can be designed as a friction-managed control: enough confidence to stop errors, but not so much ceremony that the user bypasses it. The control succeeds when the decision point is clear and actionable.

Practical implication: define clear verification outcomes that are easy for users to understand and hard to ignore.


NHI Mgmt Group analysis

Shared verification infrastructure is becoming a governance control, not just a payments feature. New Zealand’s model shows that when multiple banks rely on the same trust framework, the control point moves from individual institution logic to ecosystem coordination. That changes the security conversation from isolated account checks to shared assurance, shared standards, and shared accountability. Practitioners should read this as evidence that verification controls are increasingly architectural.

Centralising trust can reduce duplication without centralising sensitive data. The article’s operating model keeps bank records in place while standardising the verification exchange. That is the right separation for regulated ecosystems because it limits data movement while creating consistent control outcomes. The implication for identity and access teams is that federated trust models can scale only when the governance layer is explicit and reusable.

Confirmation of Payee is a close analogue to identity boundary checking in IAM. The same design logic appears in federated identity, workload identity, and delegated access: validate the claim before the action is allowed to complete. This is why shared verification models are increasingly relevant beyond banking. The practitioner takeaway is that identity assurance should be treated as an ecosystem pattern, not a single control.

Extensibility is the real benchmark, not the initial launch speed. A trust framework that can support anti-scam services and broader data sharing is more valuable than one that solves only the first use case. That matters for IAM leaders because reusable governance infrastructure reduces future implementation cost and control drift. Teams should judge shared trust models by how many adjacent use cases they can absorb without redesign.

Identity boundary enforcement at the payment layer is the emerging control pattern here. The point is not simply fraud reduction. It is that identity verification can be embedded into transactional infrastructure so that trust is checked at the moment of action, not assumed from prior enrollment. Practitioners should think about where their own programmes still trust too early.

From our research:

  • 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to 2024 Non-Human Identity Security Report.
  • 23.5% of security professionals are unsure about the biggest threat to their non-human identities, which shows how often governance gaps start with poor threat clarity.
  • The practical next step is to compare identity boundary controls across machine, human, and shared ecosystem models, using Ultimate Guide to NHIs , Standards as the framework anchor.

What this signals

Identity boundary controls are moving into shared infrastructure. As more regulated ecosystems centralise verification, IAM teams should expect the control plane to shift from local policy enforcement to ecosystem-level trust design. That will reward organisations that can separate governance from data ownership and reuse the same assurance model across multiple services.

Shared verification creates a new kind of control debt. If every partner implements the trust layer differently, the ecosystem becomes only as strong as the least standardised participant. Teams should watch for onboarding sprawl, exception handling drift, and unclear accountability at the point where a claim becomes an approved action.

The lesson extends beyond payments: any programme that validates identity, entitlement, or account ownership at scale should be designed so the trust decision can travel across organisational boundaries without exposing the underlying records. That is where federated identity, workload trust, and payment verification start to converge.


For practitioners

  • Map verification points to the decision moment Identify where your organisation still assumes trust before an action is taken. Rework those steps so the identity or account claim is checked at the point of execution, not only at enrolment or onboarding.
  • Separate trust governance from local data ownership Design shared verification services so the coordinating layer sets standards while each participant retains control of its own records and entitlements. That reduces duplication without forcing data centralisation.
  • Build reusable onboarding contracts Standardise the API, assurance, and exception-handling model for every participant so future services can reuse the same trust rails. This is what keeps ecosystem governance extensible instead of brittle.
  • Treat outcome states as control signals Use clear match, partial match, and no match responses as operational decision points. Make sure customer or operator guidance is tied to each outcome so the control changes behaviour rather than just returning a result.

Key takeaways

  • New Zealand’s Confirmation of Payee rollout shows that identity-style verification can be delivered as shared infrastructure rather than duplicated local controls.
  • The real security value is not just fraud reduction, but the ability to reuse one trust model for onboarding, verification, and future ecosystem services.
  • IAM teams should study the operating model behind the rollout because governance, not just technology, is what made the scale and speed possible.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4Shared verification controls align with managing access permissions and trust boundaries.
NIST Zero Trust (SP 800-207)The model verifies claims at action time, matching zero trust principles.
NIST SP 800-63Assurance and federation concepts help explain trusted cross-party verification.

Apply zero trust to shared ecosystem actions by checking claims at the decision point.


Key terms

  • Confirmation of Payee: A payment verification control that checks whether the recipient name matches the account details before a transfer is completed. It reduces misdirected payments and scam success by forcing a validation step at the point of action, not just at enrolment or account setup.
  • Trust Framework: A shared set of rules, assurance requirements, and technical interfaces that lets multiple organisations verify each other in a consistent way. It is the governance layer that makes cross-party trust repeatable, auditable, and scalable without requiring each participant to reinvent the control.
  • Shared Verification Infrastructure: An ecosystem control pattern where participants use a common verification service while keeping their own records and entitlement data locally. This reduces duplication and improves consistency, but it only works when governance, onboarding, and exception handling are standardised across the network.
  • Ecosystem Extensibility: The ability of a trust or identity platform to support new services without redesigning the underlying control model. In practice, it means the same verification rails, governance rules, and integration patterns can be reused as the ecosystem grows.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Raidiam: How New Zealand Reimagined Confirmation of Payee. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-08-15.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org