PayNet OFP enables secure, consumer-consented access to financial data across Malaysian institutions — banks, fintechs, pension providers, insurers, and more. The platform connects Data Consumers (DCs) requesting user data with Data Providers (DPs) supplying it, mediated through PayNet's Authorization Server and Resource Server.

mTLS, JWS signing, JWE encryption, FAPI compliance

Authorization Code flow with id_token via Token Endpoint

UTF-8 encoded, 5-second sync timeout, cursor-based pagination

1. End User initiates consent on DC application.
2. DC sends POST /par to PN with client_id and authorization_details.
3. PN sends POST /consents/events to DP with consent_id and dc_id. DP verifies JWS signature.
4. DP stores consent and acknowledges.
5. PN returns request_uri to DC.
6. DC redirects user to PN /authorize with client_id and request_uri.
7. PN redirects user to DP /authorize with OIDC params: response_type=code, client_id, redirect_uri, scope (openid), state, nonce, consent_id, signature.
8. User logs in, selects accounts, and grants authorization on DP.
9. DP calls PATCH /consents/{consent_id} at PN with status, user_identity, accounts (id_token no longer included).
10. PN acknowledges and stores consent update. Checks for duplicate consents.
11. DP redirects user to PN redirect_uri with code and state query parameters.
12. PN calls POST /v1/oauth/token at DP with grant_type=authorization_code, code, redirect_uri, and private_key_jwt client auth.
13. DP returns id_token and access_token.
14. PN validates id_token: verifies signature via DP JWKS, checks issuer, audience, expiry, nonce. Cross-references hashed_id_number with consent update.
15. PN redirects user to DC redirect_uri with authorization_code.
16. DC displays consent authorized to End User.

1. End User revokes consent on DP.
2. DP sends POST /consents/{consent_id}/revoke to PN.
3. PN acknowledges.
4. PN sends POST /consents/events to DC.
5. DC acknowledges.
6. DC notifies End User.

JWS Detached Object Signing with algorithms: PS256, ES384, ES512. Protected headers include: alg, kid, iss, jti, iat, crit. The iat is validated within a 5-minute window.

Access tokens are bound to the client's mTLS certificate. When the DC presents an access token to a Resource Server, the RS introspects the token to obtain the certificate thumbprint (cnf.x5t#S256) and validates it matches the mTLS connection. Tokens MUST NOT be transmitted in query strings.

Resource data (Account, Balances, Transactions) is encrypted with DC public cert using RSA-OAEP-256 / A256GCM. Responses are JWE inside JWS.

PN Signature Cert — PN signs request payloads. JWK use = sig.

DC Signature Cert — DC signs request payloads. JWK use = sig.

DP Signature Cert — DP signs request payloads. JWK use = sig.

DC Encryption Cert — DP encrypts data with DC cert. JWK use = enc.

JWKS responses should be cached for a maximum of 15 minutes. During key rotation, old and new keys coexist with different kid values.

Used by PN when calling the DP Token Endpoint. The client_assertion JWS body includes:

Returned in error responses from authorization and token endpoints.

Error Response Body

{
  "error": "invalid_grant",
  "error_description": "The authorization code has expired."
}

The Data Provider exposes an OAuth 2.0 / OpenID Connect Authorization Server (AS) for consent and token flows. Only the endpoints listed below are exposed on the public ingress.

For the mock DP environment the AS issuer is https://api.dp-as.openfinance.dev.inet.paynet.my/.

1. Start from the issuer URL
   The AS base URL (issuer) for this environment is https://api.dp-as.openfinance.dev.inet.paynet.my/. The issuer must match the iss claim in tokens and authorization responses.

2. Fetch the discovery document
   Request the OpenID Connect / OAuth 2.0 metadata at:

   • https://api.dp-as.openfinance.dev.inet.paynet.my/.well-known/openid-configuration
     This document contains issuer, authorization_endpoint, token_endpoint, jwks_uri, userinfo_endpoint, and other metadata. Use these URLs for all subsequent requests; do not hardcode paths.

3. Use the URLs from the discovery response
   Use the values from the discovery response for authorization, token exchange, UserInfo, and JWKS. Exact paths may differ by deployment; discovery is the source of truth.

Each of the following endpoints is exposed on the public ingress. Exact URLs are also provided in the discovery document.