Infrastructure and regtechLicence for some flows

Open banking and data aggregation testing

FintechAssuranceLabs engineers test open banking and data aggregation platforms, the category of products like Plaid, TrueLayer, and Tink. Open banking platform testing covers connection success per bank, consent and token lifecycles, pay-by-bank payment status and refunds, variable recurring payment limits, transaction categorisation, and screen scraping fallback, with evidence for regulators and partner banks in the EU, US, and Canada.

What breaks in bank connections, consents, and pay-by-bank payments

Providers charge per connection and per request, so a link without data or a stale refresh is billed for nothing or credited back. Sources below were checked on 2026-09-16.

One bank failing inside a blended success rate, then scraped. The metric counts a completed bank redirect as success, so a bank returning empty account lists stays green while clients pay connection fees for links without a balance. Article 33(3) of Delegated Regulation (EU) 2018/389 (the RTS) requires a provider to report dedicated interface problems to its competent authority without delay. For a switch to screen scraping, Article 33(4) allows use of the customer interface as a contingency until the dedicated interface is restored, and Article 33(5)(c) and (d) require access logs and a justification on request.
Background refresh outside the SCA exemption. RTS Article 10a, applicable from 25 July 2023 under Delegated Regulation (EU) 2022/2360, exempts access through an account information provider from strong customer authentication only for balances and transactions executed in the last 90 days, and requires authentication again after 180 days. A nightly job that requests 12 months of history hits authentication that no background call can complete. Request fees are still billed, and a lender decides on cached balances labelled as current. See the PSD2 SCA rules and the consent and token refresh guide.
Pay-by-bank payment shown as paid at initiation, then refunded to the wrong account. The payment API maps the bank status ACSP (accepted, settlement in process) to "paid", and the merchant releases goods for a transfer that later ends as RJCT. PSD2 Article 46(a) requires the payment initiation provider to confirm successful initiation of the payment order, an event that precedes funds arriving. For euro instant credit transfers, Article 5a(4)(e) of Regulation (EU) No 260/2012, as amended by Regulation (EU) 2024/886, requires the payer's bank to tell the provider whether the amount reached the payee, on confirmation or after 10 seconds without one. When a refund job pays the latest account linked to the customer instead of the original debtor account, PSD2 Article 88(2) releases the merchant's bank from liability under Article 89 for the incorrect unique identifier, and the merchant pays twice.
Variable recurring payment limit taken as a full first period. The UK Open Banking domestic VRP consents specification v4.0.1 pro-rates a periodic limit in the first period when PeriodAlignment is Calendar: its example yearly limit of 500.00 GBP on a consent created on 5 June 2021 allows 287.67 GBP until 31 December. A scheduler assuming the full limit submits payments the bank can reject, so consented sweeps fail and the per-payment fee is lost.
Own-account transfers categorised as income. The model labels a transfer from the customer's savings account as salary, so an income verification product billed per request overstates income. In national measures applying from 20 November 2026, Article 18(3) of Directive (EU) 2023/2225 requires a lender's creditworthiness assessment to rest on relevant and accurate information on income and expenses, appropriately verified, so a lender using the inflated figure assesses on inaccurate information.

Licence flag and the evidence regulators and partner banks ask for

Open banking carries licence flag "partial": account information and payment initiation need registration, authorisation, or accreditation, while technical services to licensed firms without possession of funds can fall outside payment licensing. Status verified on 2026-09-16.

European Union

PSD2 Article 3(j) excludes technical service providers from its scope, except for payment initiation and account information services. A provider of account information services only is exempt from most authorisation conditions under Article 33(1) and holds professional indemnity insurance as a condition of registration (Article 5(3)). A payment initiation provider that is not a credit institution, e-money institution, or other provider listed in Article 1(1) needs authorisation as a payment institution (Article 11(1)), initial capital of at least EUR 50,000 (Article 7(b)), and insurance covering its liabilities under Articles 73, 89, 90, and 92 (Article 5(2)). DORA Article 2(1)(b) and (c) covers both provider types. A payment initiation provider that supplies the payee's account identifier or name ensures that information is correct under Article 5c(2) of Regulation (EU) No 260/2012, applicable in the euro area from 9 October 2025. See PSD3 and PSR status and open banking standards. Evidence the competent authority can request:

the security policy and its risk assessment (Article 5(1)(j));
business continuity plans with their testing procedure (Article 5(1)(h));
fallback access logs and justifications (RTS Article 33(5)(c) and (d));
payee data test results for the internal procedures in Article 5c(3).

United States

The CFPB Personal Financial Data Rights rule sets authorisation, reauthorisation, and data aggregator duties for third parties; a court stayed its compliance dates on 29 October 2025, and the CFPB is reconsidering the rule (see Section 1033 status). When a pay-by-bank flow receives payer funds before paying the merchant, Section 2.01(q)(3) of the CSBS Money Transmission Modernization Act includes receiving money for transmission in money transmission, and Section 5.01(a) requires a licence for that business; each state's enacted statute and exemptions decide. Originators of online ACH debits follow Nacha's WEB debit account validation rule (effective 19 March 2021), and the fraud monitoring rule covers non-consumer Originators, Third-Party Senders, and Third-Party Service Providers regardless of volume from 19 June 2026. Evidence the partner bank asks for:

account validation results for the first use and every change of an account number;
fraud monitoring procedures and their annual review record;
authorisation and revocation test logs against the published Part 1033 text, marked as stayed.

Canada

The Consumer-Driven Banking Act received royal assent in March 2026, and the proposed Consumer-Driven Banking Regulations were published in Canada Gazette, Part I, on 27 June 2026 for 60 days of comment. On 16 September 2026, the Bank of Canada describes the regulations as proposed. Under the proposal, the Bank of Canada accredits participants other than mandated banks, phase one is read-only, consent lasts no longer than 12 months, and endpoints are available 99.5% per month. The Act's screen scraping prohibition will not be brought into force until further consultation. Initiating an electronic funds transfer at an end user's request is a payment function under section 2 of the Retail Payment Activities Act; see RPAA registration. Evidence for accreditation under the proposal:

technical standard adherence test results per endpoint;
consent management tests for expiry, renewal, and withdrawal;
baseline security test results for access control, authentication, and encryption.

Open banking and pay-by-bank test scenarios

Connector coverage. The bank connector coverage report from open banking API testing records link, first pull, and refresh per bank and API version, counting empty account lists as failures.
Consent lifecycle. Bank-side expiry before the provider's schedule, revocation at the bank and in the app, and reauthorisation on day 179 and day 181.
Token refresh. Refresh token rotation, two concurrent refreshes on one consent, and a history request past 90 days without the customer present.
Payment status. Every status from RCVD to ACSC and RJCT mapped to one merchant state, late webhooks, and polling after the 10-second instant window.
Refunds. Refunds only to the original debtor account, partial refunds capped at the original amount, and a payee name mismatch.
Variable recurring payments. Calendar and consent period alignment, first-period pro-rating, maximum individual amount, and a payment after revocation.
Data normalisation. One transaction via two banks or the fallback path yields the same sign, currency, and booking date, without pagination duplicates.
Categorisation. Own-account transfers, card refunds, and irregular salary on a labelled synthetic ledger.
Screen scraping fallback. Fallback starts only after the dedicated interface fails, stops when it recovers, and writes an access log, using synthetic credentials and account data.

Integrations and protocols to cover

Bank APIs. Berlin Group NextGenPSD2, UK Open Banking Read/Write API v4.0.1 with VRP resources, and the FDX API.
Security profiles. OAuth 2.0 with FAPI, eIDAS QWAC and QSealC certificates, and mutual TLS.
Payment rails. SEPA Credit Transfer and SCT Inst as ISO 20022 pain.001, pacs.008, and pacs.002, verification of payee requests, Nacha WEB debit files, prenotifications, and micro-entries.
Client interfaces. Aggregator REST APIs, link widgets, and consent and payment status webhooks with signature, ordering, and replay checks.
Fallback path. Headless browser sessions, one-time passcode prompts, and credential vault access.

Standards

Services

Guides

Blog posts

Sample deliverable

Sample, synthetic data

integration coverage reportIntegration coverage report: bank connectors, terminal SDK, broker API, and payout partner

Integration coverage report: bank connectors, terminal SDK, broker API, and payout partner
Connector	Happy path	Timeout and retry	Expired consent or token	Duplicate, out-of-order, or offline delivery	Coverage status and open defect
Bank connector 01 (Berlin Group NextGenPSD2)	Covered, 9 of 9 cases passed: POST /v1/consents reaches consentStatus valid after SCA, and the accounts, balances, and transactions calls return 200 for that consent	Covered, 6 of 6 cases passed: a timed-out transactions call is retried with a new X-Request-ID, and a 429 ACCESS_EXCEEDED response stops refreshes for that consent until the next day	Failed, 4 of 5 cases passed: after a 401 CONSENT_EXPIRED response, the connector keeps scheduling refreshes and shows a stale balance of 1,240.00 XTS as current	Covered, 5 of 5 cases passed: a pending transaction that returns with bookingStatus booked and a new transactionId replaces the pending entry, and overlapping dateFrom windows import no duplicates	Failed, retest scheduled after the INT-0203 fix. INT-0203 (medium): the bank connector does not set reconnect required after a 401 CONSENT_EXPIRED response
Bank feed 03 (OFX)	Covered, 7 of 7 cases passed: a STMTRQ for a checking account returns STMTRS with SONRS STATUS code 0, and each STMTTRN posts once to the ledger bank account	Covered, 4 of 4 cases passed: a statement request retried after a timeout reuses its TRNUID, and status 2019 Duplicate request is handled as already processed	Covered, 3 of 3 cases passed: SONRS status 15500 Signon invalid stops the bank feed and asks the user to reconnect, with no empty statement imported	Failed, 5 of 6 cases passed: overlapping DTSTART and DTEND windows repeat FITID values, and one repeated FITID with a changed TRNAMT imports as a second transaction	Failed, retest scheduled after the INT-0221 fix. INT-0221 (medium): a repeated FITID with a changed TRNAMT of 18.75 XTS imports as a second bank transaction
Card terminal SDK (offline mode)	Covered, 12 of 12 cases passed: online EMV contact and contactless sales return tag 8A value 00, and each approved sale posts one capture	Covered, 6 of 6 cases passed: an authorisation request with no host response before the timeout sends a reversal before the sale is retried	Covered, 4 of 4 cases passed: a terminal session token that expires while the terminal is offline is refreshed before the store-and-forward upload starts	Failed, 10 of 11 cases passed: offline sales under the terminal floor limit (tag 9F1B) complete with tag 8A value Y3, and one retried store-and-forward upload posts two captures	Blocked for release until the INT-0214 fix passes retest. INT-0214 (high): a store-and-forward upload retried after a lost acknowledgement captures one 42.50 XTS sale twice
Broker API A (FIX 4.4)	Covered, 10 of 10 cases passed: Logon (35=A) succeeds, and each ExecutionReport (35=8) with ExecType (150) F updates the imported position once	Covered, 5 of 5 cases passed: no inbound message within HeartBtInt (108) triggers a TestRequest (35=1), and a reconnect resumes at the next expected MsgSeqNum (34)	Covered, 3 of 3 cases passed: a Logon with an expired Password (554) is answered with Logout (35=5) and Text (58), and the broker link shows as disconnected with positions kept	Covered, 8 of 8 cases passed: a MsgSeqNum (34) gap triggers ResendRequest (35=2), and a resent ExecutionReport with PossDupFlag (43) Y and a known ExecID (17) is not counted as a second fill	Covered, with no open defects on Broker API A
Payout partner B (ISO 20022 pacs.008)	Covered, 8 of 8 cases passed: a pacs.008.001.08 credit transfer with a UETR returns pacs.002 TxSts ACSP and then ACSC, and the payout is marked settled once	Failed, 5 of 6 cases passed: a timed-out pacs.008 submission is followed by a pacs.028 status request, but one retry is sent as a new pacs.008 with a new UETR	Covered, 4 of 4 cases passed: a payout submitted with an expired API access token returns 401, and the token is refreshed before one resubmission with the same UETR	Covered, 6 of 6 cases passed: a pacs.002 TxSts RJCT after ACSP releases the payout hold once, and a repeated pacs.002 for the same UETR changes no balance	Blocked for release until the INT-0230 fix passes retest. INT-0230 (high): a pacs.008 retried after a timeout carries a new UETR and pays 250.00 XTS twice to one beneficiary

Amounts use XTS, the ISO 4217 code reserved for testing. Connectors, banks, and partners are generic sandbox endpoints, and terminal sales use scheme test cards masked to BIN and last four.

Questions

What is a data aggregator?

A data aggregator is a company that connects to many banks and other account providers, collects account data such as balances and transactions with the account holder's permission, and delivers that data in one normalised format to apps such as lenders and budgeting tools. The CFPB rule at 12 CFR 1033.131 defines a data aggregator as a person retained by an authorized third party to enable access to covered data.

What is screen scraping?

Screen scraping is a data collection method in which a third party signs in to a customer's online banking with the customer's credentials and extracts balances and transactions from the pages the bank shows the customer. In the EU, Article 33(4) of Delegated Regulation (EU) 2018/389 allows a provider to use the customer interface as a contingency mechanism until a bank's failed dedicated interface is restored. Canada's Consumer-Driven Banking Act contains a screen scraping prohibition that is not in force on 16 September 2026.

What is pay by bank?

Pay by bank is a payment method in which a customer pays a merchant directly from a bank account instead of with a card. In the EU, a payment initiation provider sends the payment order to the customer's bank through an open banking API after the customer authenticates, and the bank executes a credit transfer. In the US, a pay-by-bank product can link the account through a data aggregator and collect the payment as an ACH debit.

What are variable recurring payments?

Variable recurring payments (VRPs) are a series of payments that a payment initiation provider starts under one long-lived consent, with amounts and dates that can vary within limits the customer approves at the bank. The UK Open Banking VRP specification sets a maximum individual amount and periodic limits per day, week, fortnight, month, half-year, or year, and lets a bank restrict a consent to sweeping or non-sweeping use.

Scope your open banking platform testing

Send your bank coverage list, consent model, payment flows, and target markets, and we return a test scope with the evidence your regulator and partner banks will ask for.

Scope your testing