Fintech Integration Engineer Interview Questions

Option B correctly explains the TPP licence types (AISP, PISP), the ASPSP role, the eIDAS certificate requirements (QWAC, QSeal), the FAPI security profile with mTLS and PKCE, the consent flow, the UK-specific OBIE standard, Berlin Group NextGenPSD2 for the EU, and realistic integration challenges. Option A incorrectly suggests open API access without licensing or authentication — PSD2 access requires a licence and eIDAS certificates, not just an API key. Option C is dangerously wrong — open banking APIs never transmit customer credentials to TPPs; the redirect OAuth consent flow specifically prevents this. Option D is wrong — PSD2 applies across all EU member states and the UK had equivalent domestic regulation post-Brexit.

Option B correctly defines SCA's three factor categories from the RTS, explains the 3DS2 frictionless vs challenge flow distinction (the key improvement over 3DS1), describes the device fingerprint risk scoring, explains the ACS and CAVV/ECI liability shift mechanism, and lists SCA exemptions. Option A reduces SCA to a second password and misses the factor category requirements and the liability shift mechanism of 3DS2. Option C is wrong — 3DS2 requires explicit SDK or 3DS Server integration; it is not a query parameter. Option D is wrong — SCA applies to all electronic remote payments regardless of amount, with specific low-value exemptions (under EUR 30, up to 5 transactions or EUR 100 cumulative), not a EUR 1000 threshold.

Option B correctly describes all three phases with their timing, message formats (ISO 8583, ISO 20022), the role of each party (merchant, gateway, acquirer, card network, issuer), the difference between a hold and a posted debit, interchange and scheme fee structure, and — critically for a fintech engineer — the integration concerns: idempotency keys, void vs refund semantics, webhook reliability, and reconciliation. Option A collapses three distinct phases into an instant transfer and omits engineering concerns entirely. Option C incorrectly claims clearing and settlement only apply to cheques; they apply to all card transactions. Option D describes the webhook surface only, missing the authorisation flow, clearing, settlement timing, and reconciliation responsibilities.

Option B covers six concrete categories: ledger idempotency, webhook reliability with the event inbox pattern, regulatory passthrough with KYC and DORA obligations, scheme rule compliance risks, settlement float, and provider lock-in with the abstraction recommendation. Option C is wrong — BaaS providers operate under their own EMI or banking licence; your company operates as an agent or technology partner, not a licence holder (though regulatory authorisation as an agent may be required depending on the product). Option D is dangerously wrong — BaaS providers do not absorb all your compliance obligations; AML/KYC, DORA operational resilience reporting, and consumer protection rules still apply to you as the regulated agent or distributor.

Option B uses the reframing technique (exemptions are regulatory features, not loopholes), explains the TRA, low-value, recurring, and trusted beneficiary exemptions in UX-outcome terms, gives realistic frictionless rates (60-80% for TRA), explains the soft decline mechanism and the need to handle it in checkout, and sets accurate expectations about probabilistic (not guaranteed) friction reduction. Option A is wrong and unhelpful — exemptions are legally sanctioned mechanisms, not illegal workarounds. Option C describes transaction splitting to evade SCA thresholds, which is explicitly prohibited by PSD2 RTS Article 17 and constitutes scheme rule violation. Option D abdicates the engineering team's responsibility to translate regulatory complexity into product decisions.