Money movement and financial logic

Card issuing and processing testing

Card issuing and processing testing verifies the issuer side of a card programme: card lifecycle states, real-time authorisation decisions with just-in-time funding, spend controls, wallet tokenisation, clearing matched to authorisations, and issuer disputes. FintechAssuranceLabs delivers a card lifecycle test suite, an authorisation rule test matrix, a tokenisation and provisioning test report, and interchange and fee posting checks.

What card issuing and processing testing covers

We test the issuer side of a card programme: card states, authorisation decisions, device tokens, and postings after clearing. Card numbers, expiry dates, and verification codes in these flows are account data, so tests use synthetic cards on test BIN ranges. Sources in this section were checked on 2026-09-16.

Card lifecycle

We test allowed and blocked transitions between created, inactive, active, frozen, replaced, and closed states in the authorisation path, token vault, and cardholder app. Typical defects: a frozen card that still approves recurring card-not-present payments, a replacement card that loses its predecessor's spend controls, and a closed card whose wallet tokens stay active.

EU. Directive (EU) 2015/2366 Article 70(1)(e) requires the issuer to prevent all use of a payment instrument once the user notifies loss, theft, misappropriation, or unauthorised use under Article 69(1)(b). Article 68(3) requires the issuer to inform the payer of a block and its reasons, where possible before it and at the latest immediately after, unless objectively justified security reasons or other law prevent it.
US. Under 12 CFR 1005.5(b), an institution may distribute an unsolicited access device only if the device is not validated, comes with a clear explanation that it is not validated and how to dispose of it, comes with the 1005.7 disclosures, and is validated only on the consumer's request after identity verification. The lost card notice sets the 1005.6(b) liability tier (Regulation E), so freeze tests record the notice time.

Authorisation decisioning, JIT funding, and spend controls

Authorisations arrive as ISO 8583 messages or processor webhooks with a response deadline. We test each decision at its boundary: available balance, the just-in-time (JIT) funding call, velocity limits per card and account, merchant category blocks, country and channel rules, and the stand-in decision the processor applies on timeout. Failure patterns we target:

a JIT funding transfer that completes after a timeout decline, moving money with no transaction to post against;
incremental authorisations and force-posted clearings that skip the spend counter, so later requests approve against a stale limit;
a reversal message that never releases the hold.

Chip tests cover ARQC validation and Issuer Authentication Data (EMV). We also test authorisation rules that read the 3-D Secure result and the Article 11 contactless counters of Delegated Regulation (EU) 2018/389 (PSD2 SCA). PCI DSS v4.0.1 Requirement 3.3.3 lets issuers store sensitive authentication data only for a legitimate issuing business need, secured and, after 31 March 2025, encrypted with strong cryptography; we search authorisation logs and retry queues for stray verification codes and PIN blocks (PCI DSS).

Tokenisation and wallet provisioning

Push provisioning from the issuer app and manual card entry in a wallet both end in a token bound to one device. We test identification and verification, token status on freeze, replace, and close, token updates on reissue, and Payment Account Reference consistency against the EMV Payment Tokenisation Specification Technical Framework v2.4 (EMVCo, published 9 July 2026). For EU issuers, EBA Q&A 2020_5622 requires SCA under PSD2 Article 97(1)(c) when a token is created through a remote channel with the payer's participation. Q&A 2022_6464 states that a new token replacing an existing one and bound to a device or user would require SCA. A replacement flow that refreshes tokens silently passes functional tests and still fails that answer.

Clearing, presentment matching, and fee posting

Tips, hotel incrementals, fuel pre-authorisations, split shipments, and currency conversion change the cleared amount, and some presentments have no authorisation. We test matching keys, hold release on match and expiry, over- and under-presentment, multiple clearings per authorisation, and interchange and fee posting. For card payments initiated by or through the payee with the exact amount unknown at consent, PSD2 Article 75(1) lets the issuer block only the amount the payer consented to, and 75(2) requires release without undue delay after receiving the exact amount, at the latest immediately after receipt of the payment order. A hold left after clearing breaks 75(2) and counts spend twice against the balance. Programme-level reconciliation belongs to ledger and reconciliation testing.

Issuer-side disputes

We test the issuer path from dispute case to provisional credit, network chargeback, and final or reversed credit. For US consumer accounts, an institution may extend a 10-business-day investigation to 45 days if it provisionally credits within 10 business days, informs the consumer within two business days, and corrects and reports on time (12 CFR 1005.11(c)(2)(i) to (iv)). The 45-day limit becomes 90 days for point-of-sale debit card transactions (1005.11(c)(3)(ii)(B)). In the EU, Article 73(1) requires the payer's provider to refund an unauthorised transaction immediately, and at the latest by the end of the following business day after noting or being notified of it, unless it has reasonable grounds to suspect fraud and communicates them in writing to the relevant national authority.

Segments

Standards

Guides

Scenarios

QA before a partner bank integration goes live

Deliverables

Card lifecycle test suite (create, activate, freeze, replace, close)
Automated tests for every card state transition, each checked against the authorisation decision, the wallet token status, and the cardholder notice, that run in the client's CI pipeline.
Spend control and authorisation rule test matrix
One row per authorisation rule with test values below, at, and above each limit, plus the expected and actual decision, for engineering leads and issuing bank programme reviewers.
Wallet tokenisation and provisioning test report
Push and manual provisioning results per wallet with the verification path, the authentication result, and the token status after card freeze, replacement, and closure, for product and compliance leads.
Interchange and fee posting checks against the ledger
Queries that compare the interchange revenue and programme fees posted per cleared card transaction with the amounts in the network clearing records, for finance and engineering leads.

How card issuing tests fit your release process

Issuer defects such as a hold that survives a reversal appear only when a sequence of network messages reaches a card in a given state, so the suites replay message sequences instead of single calls.

On every merge. The lifecycle suite and the authorisation rule matrix run in your CI against the issuer processor's sandbox or a message simulator. Each case sends authorisation, advice, reversal, and clearing in a set order and asserts the decision, balance, hold, and card state.
Before release. Tokenisation tests run against the wallet and token service test environments, which are shared and slower, so they run on release candidates. The matrix is re-run in full when a limit, merchant category list, or funding rule changes, because a threshold moved in configuration breaks without a code diff.
After release. A smoke set runs lifecycle and authorisation checks on a card your programme designates for testing. The first clearing cycle after release goes through the interchange and fee posting checks.

Test data is synthetic: processor test BIN ranges, network test cards from the test card numbers guide, and generated cardholders. Production account data is not copied into test environments, and engineers work under the access rules on the security page.

Handover is in your formats. Suites live in your repository and CI. The rule matrix maps each row to a rule ID in your decision engine. The tokenisation report keeps a provisioning trace per wallet. The posting checks are SQL queries against your ledger schema. For programmes with a sponsor bank, the matrix and lifecycle results go into the bank's programme review; the Banking-as-a-Service segment page lists what those banks ask for.

Your team owns sandbox credentials, BIN range configuration, rule approval with the issuing bank, and production changes. We own the test design, the suites until handover, and the evidence for each release.

Sample deliverable

Sample, synthetic data

rule and threshold test matrixRule and threshold test matrix: transaction monitoring, disputes, collections, expense, market data, and claims rules

Rule and threshold test matrix: transaction monitoring, disputes, collections, expense, market data, and claims rules
Rule ID	Rule and reference	Test values below, at, and above the boundary	Expected outcome	Actual outcome	Result
TM-STR-01	Transaction monitoring structuring rule: open an alert when one customer makes two or more cash deposits on one business day, each below USD 10,000.00, that total more than USD 10,000.00. Built on 31 CFR 1010.313(b): multiple currency transactions shall be treated as a single transaction if the institution knows they are by or on behalf of any person and total more than $10,000 during any one business day	Below: two cash deposits totalling USD 9,999.99; at: two cash deposits totalling USD 10,000.00; above: two cash deposits totalling USD 10,000.01	The USD 9,999.99 and USD 10,000.00 totals open no structuring alert; the USD 10,000.01 total opens a structuring alert and a currency transaction report flag	The USD 9,999.99 and USD 10,000.00 totals opened no structuring alert; the USD 10,000.01 total opened a structuring alert and a currency transaction report flag	Passed, 3 of 3 test values, run 2026-09-14
SAN-SCORE-01	Sanctions name-match score threshold: open a screening alert and hold the payment when the name match score against a sanctions list entry is 85 or higher. Configured screening policy; no regulation sets the score	Below: match score 84; at: match score 85; above: match score 86, each for a synthetic customer name against a synthetic list entry	Match score 84 opens no alert; match scores 85 and 86 open a screening alert and hold the payment	Match scores 84 and 85 opened no alert and released the payment; match score 86 opened a screening alert and held the payment	Failed: the comparator uses greater than 85 instead of 85 or higher; defect DEF-2210, critical severity, blocks release
CBK-DL-13.1	Chargeback response deadline for Visa Dispute Condition 13.1 (Merchandise/Services Not Received): block submission of the response package after the network time limit. Visa Core Rules and Visa Product and Service Rules, 18 April 2026 edition, section 11.2.3, Table 11-2: the Dispute Response time limit is 30 calendar days from the Dispute Processing Date, with listed regional exceptions for some domestic transactions	Below: calendar day 29 after the Dispute Processing Date; at: calendar day 30; above: calendar day 31, all dates counted in UTC	Calendar days 29 and 30 accept the response package for submission; calendar day 31 blocks submission and marks the dispute case as expired	Calendar days 29 and 30 accepted the response package for submission; calendar day 31 blocked submission and marked the dispute case as expired	Passed, 3 of 3 test values, run 2026-09-14
COL-CALL-01	Regulation F call frequency: block a further collection call to a person about a particular debt after seven calls within seven consecutive days. 12 CFR 1006.14(b)(2)(i)(A) and (b)(2)(ii): subject to the exclusions in (b)(3), a debt collector is presumed to comply if it places a telephone call to a particular person about a particular debt not more than seven times within seven consecutive days, and is presumed to violate the rule if it places calls in excess of that frequency	Below: sixth call to one person about one debt within seven consecutive days; at: seventh call; above: eighth call	The sixth and seventh calls are placed; the eighth call is blocked by the dialer and rescheduled after the seven-consecutive-day period	The sixth and seventh calls were placed; the eighth call was blocked by the dialer and rescheduled after the seven-consecutive-day period	Passed, 3 of 3 test values, run 2026-09-14
EXP-RCPT-01	Expense policy receipt threshold: require a receipt before submission of a non-lodging expense of USD 75.00 or more. 26 CFR 1.274-5(c)(2)(iii)(A)(2): except as provided in (c)(2)(iii)(B), documentary evidence is required for any expenditure other than lodging of $75 or more, except that documentary evidence for transportation charges is not required if not readily available	Below: meal expense of USD 74.99; at: meal expense of USD 75.00; above: meal expense of USD 75.01	The USD 74.99 meal expense submits without a receipt; the USD 75.00 and USD 75.01 meal expenses are blocked until a receipt is attached	The USD 74.99 and USD 75.00 meal expenses submitted without a receipt; the USD 75.01 meal expense was blocked until a receipt was attached	Failed: the rule uses greater than USD 75.00 instead of USD 75.00 or more; defect DEF-2213, medium severity, fix scheduled for the next release and does not block this release
MD-ENT-01	Market data non-professional subscriber entitlement: grant the non-professional entitlement only to a natural person who is not registered or qualified in any capacity with the SEC, the CFTC, any state securities agency, or any securities exchange or association; not engaged as an investment adviser under Section 202(a)(11) of the Investment Advisers Act of 1940, whether or not registered; and not employed by an exempt bank or organization to perform functions that would require registration. Nasdaq Equity 7, Section 147(d)(4)(A), as quoted in SEC Release No. 34-94466 of 18 March 2022	Below: natural person with no registration and no adviser role; at: natural person acting as an unregistered investment adviser; above: subscriber account opened in a company name	Only the natural person with no registration and no adviser role receives the non-professional entitlement; the unregistered investment adviser and the company account receive the professional entitlement	The natural person with no registration and the unregistered investment adviser received the non-professional entitlement; the company account received the professional entitlement	Failed: the status attestation checks registration only, so subscriber counts reported to the exchange are wrong; defect DEF-2211, high severity, blocks release
CLM-AUTO-01	Claim auto-approval limit: approve a claim without adjuster review when the payable amount after the deductible is XTS 2,500.00 or less. Configured claims authority limit; no regulation sets the amount	Below: payable amount of XTS 2,499.99; at: payable amount of XTS 2,500.00; above: payable amount of XTS 2,500.01	The XTS 2,499.99 and XTS 2,500.00 claims are approved automatically and queued for payment; the XTS 2,500.01 claim goes to adjuster review with no payment queued	The XTS 2,499.99 and XTS 2,500.00 claims were approved automatically and queued for payment; the XTS 2,500.01 claim went to adjuster review with no payment queued	Passed, 3 of 3 test values, run 2026-09-14

Rule IDs, defect IDs, customers, claims, and run dates are synthetic, USD appears only where a regulation states the threshold in USD while configured limits use XTS (the ISO 4217 test code), and rule references were checked on 2026-09-16 against eCFR, the Visa Core Rules and Visa Product and Service Rules of 18 April 2026, and SEC Release No. 34-94466.

Questions

What is a card issuer?

A card issuer is the bank or licensed institution that provides a payment card to a cardholder, holds the card account, and approves or declines each authorisation request. In many fintech card programmes, a sponsor bank is the issuer of record, an issuer processor runs the authorisations, and the fintech company designs the product and the spend rules.

What is card tokenization?

Card tokenization replaces the card number with a payment token that a token service provider maps back to the card number. A wallet token is bound to one device and can be limited to a channel or merchant, so a stolen token has little use elsewhere. The EMV Payment Tokenisation Specification defines the roles and the Payment Account Reference.

Scope your card issuing testing

Send your issuer processor set-up, funding model, and spend rules, and we return a test scope for lifecycle, authorisation, tokenisation, and posting flows.

Scope your testing