Open Banking API Interview Questions: Worked Answers and Debugging Exercises

A useful technical answer explains a decision, the evidence behind it and what could make it wrong. In financial API work, that often means distinguishing a successful HTTP request from a valid authorization decision, or a retryable read from an operation whose outcome is unknown.

The questions below are original practice prompts, not a collection of questions attributed to specific employers. Say your answer aloud, draw the request path and identify a test that would challenge your assumption. If you need the wider learning sequence first, start with the developer roadmap.

Authorization and trust

1. You can decode a JWT. Can you trust it?

Worked answer: decoding exposes its contents. Trust requires verification under an expected policy: the accepted algorithm and key, issuer, audience and applicable time and token-type constraints. Establish those expectations from trusted configuration, rather than accepting whatever the token asks for. The JWT Best Current Practices discusses algorithm verification, issuer and audience validation, and confusion between token contexts.

Follow-up: a token has a valid signature but belongs to a different API. What test rejects it? Describe a wrong-audience test and its expected failure, then explain why displaying the decoded payload is still useful for diagnosis.

2. What does PKCE prove?

Worked answer: it links the authorization request to the later code exchange using a per-transaction verifier. For S256, the challenge is the base64url encoding of the verifier's SHA-256 digest. The token endpoint checks that the submitted verifier matches the original challenge. PKCE does not replace every other client or transaction validation. See RFC 7636.

Follow-up: two browser tabs begin authorization. Explain where each transaction's verifier is kept, how the callback selects the right transaction and how you prevent reuse. Avoid a single global verifier variable that is overwritten by the second tab.

3. How do client authentication and token binding differ?

Worked answer: client authentication identifies the application to the authorization server. Sender constraint limits how an access token can be presented to the resource server. In the FAPI 2.0 Security Profile, the permitted mechanisms and their combinations are explicitly defined. Read the provider's chosen configuration instead of inferring it from one JWT or certificate.

Follow-up: an application authenticates with a signed assertion. Does that alone mean a stolen access token cannot be replayed? Explain what proof or certificate the resource server additionally expects, and how that requirement is enforced.

4. A certificate is in date. Why might TLS still fail?

Worked answer: validity dates are one part of verification. Investigate the intended hostname, chain and trust store, then any client-certificate requirements. Reading a certificate's fields does not validate the connection. Keep server authentication and client authentication separate in your diagram.

Follow-up: explain the next diagnostic step for a hostname mismatch versus an unknown issuer. A good answer preserves verification and fixes the configuration or trust material. Use our certificate validation guide to review the workflow.

5. Is an unexpired token sufficient to read transactions?

Worked answer: first identify the complete access policy. The token must be valid for this resource and operation, and any applicable consent must permit the requested access. Revocation, account selection and ecosystem-specific rules can matter independently of the token's expiry. Explain which decisions the authorization server, resource server and application each own.

Follow-up: permission is revoked during a refresh. State how your application stops using the result and how it represents the failure to the user. Do not claim that a local status field alone enforces the provider's policy.

Data and reliability

6. A payment request times out. Do you retry it?

Worked answer: establish whether the request may have reached the server and what the provider guarantees. A transport timeout does not prove the operation failed. Use the provider's documented idempotency and status-retrieval behavior where available. Preserve the same logical operation identifier when the contract requires it.

Stripe's idempotent request documentation is one concrete contract to study. Its semantics should not be assumed for another provider. Ask about retention, payload mismatches and which responses are persisted before designing a retry policy.

Follow-up: what happens if your process crashes after sending the request? Discuss durable operation state and reconciliation, including what the user sees while the outcome is uncertain.

7. How do you handle a 429 response?

Worked answer: stop treating the operation as a normal success, inspect the provider's guidance and decide when another attempt is allowed. A production policy needs a bounded attempt count or deadline, cancellation and coordination so many workers do not retry together. Respect a valid server retry hint within your application's limits.

Follow-up: how would you test this without waiting a minute? Inject the clock or scheduling boundary, return a synthetic rate-limit response and verify that the caller observes the intended delay or explicit failure. Avoid a test that simply replaces all waiting with immediate retries.

8. Why might pagination return duplicate transactions?

Worked answer: pages can overlap, data can change while fetching, or the provider's pagination model may have different snapshot guarantees. Read that contract before choosing a strategy. Stable identifiers can support deduplication, but a repeated identifier with changed fields needs an explicit policy.

Follow-up: if page two fails, is the result complete? Name the completeness state in your response model. Detect repeated cursors and cap the traversal so a malformed upstream response cannot create an endless loop.

9. Why use integer minor units in a small money model?

Worked answer: it avoids representing decimal monetary amounts as binary fractions in the example. The model still needs a currency and an explicit scale. A value of 1250 is only interpretable with that contract. Different currencies and upstream formats need deliberate conversion rules; do not assume every currency has two decimal places.

Follow-up: how do you handle a decimal string from a provider? Describe exact parsing, permitted precision, bounds and rejection of invalid input. Do not combine totals across currencies without an explicit conversion model.

10. What belongs in an integration support report?

Worked answer: include the expected behavior, observed behavior, environment, request correlation identifier, timing and a minimal synthetic reproduction. Explain what changed and what you already ruled out. Exclude credentials and customer financial data.

Follow-up: the partner cannot reproduce it. Identify the smallest remaining difference: endpoint version, client registration, scope, certificate configuration or a specific payload shape. Propose one experiment with a predicted result for each hypothesis.

Three practical exercises

Exercise A: diagnose a token rejection

Run the JWT verification failure lab. Before executing each case, predict whether it fails on signature or claims. Use the JWT tool to read the synthetic header and payload. Your deliverable is a table containing the input change, expected failure and evidence from the verifier.

Exercise B: investigate a repeated page

Download the account-data lab and run it with Node.js 22 or later:

node account-data-lab.mjs

Expect 10 checks passed. Find the pagination-loop case and explain why a cursor that repeats must not be requested forever. Then change the mock transport so it returns two different records with the same identifier. Predict the result before running it. The full project context is in the portfolio guide.

Exercise C: write a recovery decision

A transaction refresh succeeds on its first page and receives a 429 on its second. Write the UI message and the storage decision. Will an earlier complete snapshot remain visible with its timestamp? How will a user distinguish that snapshot from a successful new refresh? There is room for different product choices; your answer should make the state and tradeoff explicit.

Review your answers

Score each answer against four questions: did you identify the relevant contract, name a failure mode, propose a meaningful test and state what remains uncertain? An answer full of protocol names but without an observable outcome needs another pass.

Bring a short runnable demonstration to a portfolio discussion and keep a longer explanation available. Ask the interviewer which failure their team encounters most often; that can turn an abstract question into a productive engineering conversation. Explore the employer directory when you are ready to research teams, and check each employer's own description for the actual role expectations.