Third Party Providers

Legal identity, permitted roles and controlled access

Know the party behind the application

In open banking, a third-party provider delivers a service such as account information or payment initiation. The customer may recognise a brand while the legal entity, authorised role and technical operator are different. The account-servicing institution needs to establish the actual access chain under the relevant framework.

A regulated provider is not necessarily an outsourced supplier of the bank. Mandatory access may limit the bank's discretion to treat every TPP as a commercial vendor it can choose or reject. Apply objective regulatory and security requirements; do not invent extra approval barriers from an unrelated procurement process.

Identity, role and credential

Verify the legal entity and permitted activities against the applicable authoritative register or accreditation source. Validate the production credential through the ecosystem's trust process. A credential identifies technical assertions; it does not grant every customer scope or prove that authorisation has never changed.

European PSD2, UK Open Banking and Australian CDR use different instruments and participant models. Qualified certificates, directory entries and accreditation are not interchangeable. Follow the current profile for the market, including the treatment of expiry, withdrawal and relevant roles.

Request-level authority

An authorised information provider is not automatically permitted to initiate a payment. A permitted role does not establish the customer's instruction for a particular account. Bind caller identity, role, relevant permission and target resource to the actual request.

Intermediary or agent models need a clear chain of authority and attribution. Identify whether the intermediary is merely a processor, acting for a principal or providing its own regulated service. Use the applicable rules and contracts rather than assuming a principal's licence covers every downstream actor.

Keep production and sandbox identities distinct. A successful test with a sandbox credential does not establish the production entity's standing or that its production client uses the same configuration. Promotion should verify the required identity, role, technical conformance and operational contacts without adding unlawful access obstacles.

Ongoing status and incidents

Authorisation, credentials, software registration and customer permissions can change independently. Define how authoritative updates reach enforcement, what checks apply on a request and how affected access is stopped. Do not keep accepting requests merely because old tokens have time left after their authority has ended.

Availability and suspension decisions should be based on the actual legal and security framework. A suspected security incident may require targeted containment and communication; it does not automatically justify denying every third-party customer indefinitely.

Worked example: valid firm, wrong role

In this fictional case, a provider authorised for account information sends a payment request. Its credential is technically valid and the customer has a read permission, but neither establishes payment-initiation authority. The bank refuses the unsupported action, records the reason and gives a suitable response through the contract.

Operations determines whether it was a configuration error or attempted misuse and coordinates appropriate action. It should not mislabel every denied call as confirmed fraud, nor broaden the role simply to make the integration pass.

Evidence and customer support

Correlated references should allow an investigator to connect the firm, customer authority, endpoint, decision and resulting business outcome. Different parties may hold relevant evidence. Contacts and information-sharing paths need to work during a dispute, with appropriate confidentiality and access controls.

Monitor denied roles, invalid credentials, status-update lag, unexplained scope requests and unresolved incidents. Complaint and payment liability depends on the relevant law and facts; a generic acceptance timestamp does not settle it. The EBA PSD2 rulebook, UK Open Banking standards and CDR guidance are distinct reference points.

Takeaway

Trust in a TPP joins legal standing, technical identity, permitted role and the customer's actual authority. Maintain that chain throughout the relationship and on the requests that depend on it.

Continue to Developer Portals & Sandboxes.