Digital identity is becoming the foundation of finance in ASEAN and ANZ

At a glance

What this is: This is an industry commentary on how digital identity is becoming the trust layer for financial services transformation across ASEAN and ANZ.

Why it matters: It matters because IAM teams must align customer authentication, transaction assurance, and data-sharing controls with rapid fintech expansion and rising fraud pressure.

👉 Read Ping Identity's analysis of digital identity in ASEAN and ANZ finance

Context

Financial services in ASEAN and ANZ are changing fast, but the central problem is not digitization itself. The harder issue is trust at scale: institutions have to prove who a customer is, whether a transaction is safe, and whether data sharing is appropriate while channels, partners, and fraud patterns keep changing.

In that environment, digital identity is no longer just an access layer. It sits between customer experience, fraud resistance, regulatory confidence, and the ability to launch new services without weakening controls. For IAM leaders, that makes identity architecture a business capability rather than a technical dependency.

Key questions

Q: How should financial services teams use IAM to support digital growth?

A: Financial services teams should treat IAM as a trust framework for customer identity, transaction safety, and data sharing. That means aligning authentication strength, authorization rules, and consent handling to the risk of each channel and use case. If the identity layer cannot support those decisions consistently, digital growth will scale exposure as quickly as it scales revenue.

Q: Why does fraud pressure change identity and access management priorities?

A: Fraud pressure changes IAM priorities because login success alone does not prove that a transaction or data request is legitimate. Financial institutions need stronger context, such as device risk, session behaviour, and transaction sensitivity, so identity decisions can respond to abuse patterns instead of only verifying the first sign-in.

Q: What do organisations get wrong about digital identity in financial services?

A: Many organisations treat digital identity as a customer experience layer and underinvest in its governance role. In practice, identity is also where security, trust, and regulatory expectations intersect. If that governance is weak, new payment products and API integrations inherit the same control gaps.

Q: Who is accountable when identity controls fail in open banking ecosystems?

A: Accountability usually sits with the institution that defines the identity and authorization model, even when partners consume the API. The organisation must prove that consent, access scope, and transaction trust were governed correctly. Frameworks such as the NIST Cybersecurity Framework and identity assurance guidance help define those responsibilities.

Technical breakdown

Digital identity as the trust layer for financial services

Digital identity in financial services covers how an organisation establishes, reuses, and verifies identity across onboarding, login, transaction approval, and data-sharing events. In a connected banking environment, IAM must support more than access control. It has to bind identity proofing, authentication strength, and authorization decisions to business risk, customer context, and regulatory expectations. That is why identity becomes the connective tissue between innovation and security. If identity assurance is weak, every new digital wallet, API integration, or open banking flow inherits that weakness.

Practical implication: align identity assurance levels to the specific transaction and data-sharing risk, not just to channel convenience.

Why fraud pressure changes IAM priorities

The article links digitization to rising fraud threats, which means identity controls are being asked to do more than support sign-in. They must help distinguish legitimate customer behaviour from account takeover, transaction manipulation, and unauthorised data release. In finance, this shifts IAM toward continuous proof rather than one-time verification. Stronger identity signals, step-up checks, and contextual decisioning matter because the objective is not merely authenticating a user once, but maintaining trust through the full transaction lifecycle.

Practical implication: treat fraud resistance as an identity design requirement, not a downstream detection problem.

Open banking APIs demand tighter data-sharing governance

Open banking and similar API ecosystems increase the number of places where identity, consent, and authorization can fail. Each API call can become a trust decision about who is requesting access, what data is being shared, and whether the request still fits the original consent or policy boundary. That makes digital identity central to shared-data models. Without reliable identity governance, APIs expand the attack surface faster than the business can monitor it.

Practical implication: map API permissions to explicit identity and consent controls before expanding partner access.

NHI Mgmt Group analysis

Digital identity has become the control plane for financial trust. The article is right to frame identity and access management as the connective tissue between innovation, security, and scale. In financial services, trust is not an abstract brand attribute. It is enforced through proof of identity, transaction assurance, and data-sharing governance, all of which depend on IAM decisions that are consistent across channels. Practitioners should treat identity design as a business-risk control, not a login project.

Fraud pressure is forcing IAM to move from authentication to assurance. As digital channels multiply, a single successful login is no longer enough to establish trust. Financial institutions need to validate the transaction context, the device or session risk, and the legitimacy of data-sharing requests as part of the identity decision. That shifts the programme away from static access checks and toward continuous verification.

Open banking expands the blast radius of identity mistakes. Every API relationship introduces another place where identity, authorization, and consent can drift apart. If the identity layer is weak, partner integrations scale exposure as quickly as they scale revenue. The implication is that API growth and identity governance must be designed together, or the institution inherits unmanaged trust gaps.

Identity debt: a growing mismatch between the speed of financial digitization and the maturity of identity controls. The article describes a market where institutions are moving faster than their trust architecture. That creates recurring gaps between customer experience goals and the identity checks needed to sustain them. Practitioners should measure whether their identity programme can support new channels without reintroducing manual verification or policy exceptions.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly hidden identity sprawl can outrun governance.
• For a broader control baseline, Ultimate Guide to NHIs , Regulatory and Audit Perspectives shows how audit pressure is forcing identity teams to document access, rotation, and offboarding.

What this signals

Financial services leaders should expect identity programmes to absorb more of the responsibility for fraud prevention and data-sharing trust. The practical shift is toward identity decisions that are contextual, auditable, and tied to transaction risk rather than channel convenience.

Identity debt: the gap between rapid financial digitization and mature identity governance will become the main constraint on safe scale. Institutions that cannot prove identity at the point of decision will keep adding manual review, exceptions, and compensating controls.

The governance benchmark is moving from whether authentication works to whether the identity layer can support new payment, API, and consent models without weakening assurance. That is where IAM maturity will start to separate scalable programmes from fragile ones.

For practitioners

• Tie identity assurance to transaction risk Define assurance requirements by transaction type, data sensitivity, and partner exposure so the same authentication flow is not reused for every financial interaction.
• Extend IAM into API governance Inventory open banking and partner APIs, then map each one to explicit identity, consent, and authorization rules before expanding access.
• Add fraud signals to identity decisions Use device, session, and behavioural context to support step-up checks where account takeover or transaction abuse is most likely.
• Review trust controls before scaling new channels Test whether new wallets, payment flows, or data-sharing features can inherit existing identity controls without creating exceptions or manual overrides.

Key takeaways

• In ASEAN and ANZ financial services, digital identity is now the trust layer that links customer proof, transaction safety, and data-sharing decisions.
• The main risk is identity debt, where fast-moving digital channels outpace the governance needed to keep fraud and access decisions reliable.
• IAM teams should design for transaction assurance and API governance together, or new services will scale exposure as quickly as they scale reach.

Key terms

• Digital Identity: Digital identity is the collection of attributes, credentials, and assurance signals used to recognise and govern a user or system in online environments. In financial services, it must support both customer experience and risk decisions, including authentication strength, transaction approval, and controlled data sharing.
• Identity Assurance: Identity assurance is the degree of confidence an organisation has that an identity is genuine and being used by the right party. In practice, assurance depends on how identity was proofed, how strongly it is authenticated, and whether the current session still matches the expected risk.
• Open Banking API: An open banking API is a controlled interface that lets third parties request account or payment data under defined rules and consent conditions. For identity teams, the API is not just a technical endpoint. It is a governance boundary where authorization, consent, and trust must all be verified.
• Identity Debt: Identity debt is the gap that forms when business speed outpaces the maturity of identity controls and governance. It appears when new channels, integrations, or customer journeys are launched faster than the organisation can prove identity, manage consent, and maintain consistent authorization decisions.

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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by Ping Identity: digital identity and the future of finance across ASEAN and ANZ. Read the original.