spb/air Public MIT
AIR — The Language of Accounting.
Python 100%
1<!--2Project : AIR — Accounting Intermediate Representation3Author : Simon-Pierre Boucher4Contact : contact@spboucher.ai5File : bank-statement-formats.md6-->78# Bank Statement Formats & Reconciliation Research910Research for Phase 6 (bank reconciliation): parsing bank statements (camt.053, MT940)11and matching statement lines against ledger cash movements. All findings below are12sourced from web research performed on **2026-08-05**; nothing is from memory.1314---1516## 1. ISO 20022 camt.053 — BankToCustomerStatement1718camt.053 is the ISO 20022 XML end-of-day bank account statement (the "MX" successor19to MT940). It is part of the Bank-to-Customer Cash Management message set maintained20by the ISO 20022 Registration Authority (iso20022.org).2122### 1.1 Document root and namespace2324- Root element: `<Document>` with a version-specific default namespace:25 `urn:iso:std:iso:20022:tech:xsd:camt.053.001.NN` (e.g. `camt.053.001.02`,26 `camt.053.001.08`). **The version is identified via the XML namespace**, so the27 parser must read the namespace, not assume one.28- Inside: `<BkToCstmrStmt>` (BankToCustomerStatement), containing one `<GrpHdr>`29 and one or more `<Stmt>` blocks (one per account/period).3031### 1.2 Structure (elements the AIR parser must handle)3233```34Document @xmlns = urn:iso:std:iso:20022:tech:xsd:camt.053.001.NN35└── BkToCstmrStmt36 ├── GrpHdr37 │ ├── MsgId unique message id38 │ └── CreDtTm file creation timestamp (ISO 8601)39 └── Stmt [1..n] one per account statement40 ├── Id statement id41 ├── ElctrncSeqNb electronic sequence number (optional)42 ├── CreDtTm statement creation timestamp43 ├── Acct44 │ ├── Id/IBAN or Id/Othr/Id account identifier (IBAN or domestic)45 │ └── Ccy account currency (ISO 4217)46 ├── Bal [1..n] balances47 │ ├── Tp/CdOrPrtry/Cd OPBD=opening booked, CLBD=closing booked,48 │ │ CLAV=closing available, OIBD/CIBD=interim (multi-page)49 │ ├── Amt @Ccy decimal amount, currency as XML attribute50 │ ├── CdtDbtInd CRDT | DBIT (sign of the balance)51 │ └── Dt/Dt balance date52 └── Ntry [0..n] statement entries (transactions)53 ├── NtryRef entry reference (optional)54 ├── Amt @Ccy ALWAYS positive decimal; currency attribute mandatory55 ├── CdtDbtInd CRDT (money in) | DBIT (money out) — gives the sign56 ├── RvslInd true if this entry reverses a previous one (optional)57 ├── Sts BOOK (booked) | PDNG (pending) | INFO58 ├── BookgDt/Dt (or /DtTm) booking (posting) date59 ├── ValDt/Dt (or /DtTm) value date60 ├── AcctSvcrRef bank's own reference (optional)61 ├── BkTxCd bank transaction code (Domn/Fmly/SubFmlyCd or Prtry/Cd)62 ├── NtryDtls [0..n]63 │ ├── Btch batch info (NbOfTxs, TtlAmt) when 1 entry = n transactions64 │ └── TxDtls [0..n] underlying transactions65 │ ├── Refs/EndToEndId payer-assigned end-to-end reference (invoice/PO ref)66 │ ├── Refs/TxId, InstrId, MndtId67 │ ├── AmtDtls InstdAmt / TxAmt (useful for FX)68 │ ├── RltdPties Dbtr / Cdtr names and accounts69 │ └── RmtInf/Ustrd unstructured remittance info (free text)70 │ RmtInf/Strd structured remittance (creditor reference etc.)71 └── AddtlNtryInf free-text description of the entry72```7374Key semantics:7576- **`Amt` carries no sign**; direction comes exclusively from `CdtDbtInd`77 (`CRDT` = credit to the account = money received; `DBIT` = money out).78- The currency is the mandatory `Ccy` **attribute** on `Amt`.79- One `Ntry` may aggregate many underlying transactions (batch/lump-sum entries):80 `NtryDtls/Btch` + repeated `TxDtls`. This is the structural basis for81 one-to-many reconciliation matching.82- `EndToEndId` (max 35 chars) travels unaltered from the payment initiation83 (pain.001) to the statement — it is the best deterministic matching key.8485### 1.3 Version differences (brief)8687- Common versions in the wild: `.02` (2009 base, still the most widely delivered88 by banks, e.g. Nordea, Dutch banks), `.06`, `.08` (2019 — the CBPR+/SEPA-aligned89 version banks are converging on), `.10`/`.11`/`.13` (latest, Feb 2025).90- Newer versions mostly **add optional fields without removing existing ones**;91 the structural core (`GrpHdr` / `Stmt` / `Bal` / `Ntry`) is stable across versions.92 Notable mechanical difference: in `.02` `Sts` is a simple code93 (`<Sts>BOOK</Sts>`); in `.08+` it becomes a complex element94 (`<Sts><Cd>BOOK</Cd></Sts>`). Party identification blocks also gain structure95 in `.08+`.96- Practical parser strategy (used by open-source parsers): parse97 namespace-tolerantly, target the common core, handle the `Sts` shape difference.9899Sources: iso20022.org Message Definition Report Part 2 (Bank-to-Customer Cash100Management), Payments Canada camt.053.001.08 usage guideline, Nordea101camt.053.001.02 standard, ValidateFin structural guide, darko-mijic camt.053102parser spec (URLs in §7).103104---105106## 2. MT940 — SWIFT Customer Statement Message107108MT940 is the legacy SWIFT FIN "MT" end-of-day customer statement: a line/tag-based109text format. Still extremely widespread in bank connectivity (EBICS, host-to-host,110e-banking exports) even though it is deprecated by SWIFT (see §3).111112### 2.1 Tag structure113114| Tag | Name | Format | Notes |115|---|---|---|---|116| `:20:` | Transaction Reference Number | 16x | Sender's reference for the message |117| `:25:` | Account Identification | 35x | Account number (option `P` adds BIC) |118| `:28C:` | Statement Number/Sequence | 5n[/5n] | e.g. `151/1` |119| `:60F:` | Opening Balance (First) | 1!a6!n3!a15d | D/C mark + date YYMMDD + currency + amount |120| `:61:` | Statement Line | see §2.2 | Repeats per transaction |121| `:86:` | Information to Account Owner | 6*65x | Optional; up to 6 lines × 65 chars; must follow its `:61:` |122| `:62F:` | Closing Balance (Final) | 1!a6!n3!a15d | Same layout as `:60F:` |123| `:60M:`/`:62M:` | Intermediate opening/closing balances | same | Used when a statement spans multiple messages |124| `:64:`/`:65:` | Closing available / forward available balance | same layout | Optional |125126Constraint: a `:86:` must be preceded by a `:61:` and belongs to it; when a127period spans several messages, all but the last carry `:62M:` and the last128carries `:62F:`.129130### 2.2 The `:61:` statement line — full format specification131132```133:61: 6!n [4!n] 2a [1!a] 15d 1!a3!c 16x [//16x] [34x]134 │ │ │ │ │ │ │ │ └─ supplementary details (optional, new line)135 │ │ │ │ │ │ │ └─ bank reference (optional, after //)136 │ │ │ │ │ │ └─ customer reference (16x; NONREF if none)137 │ │ │ │ │ └─ transaction type code: 1 letter + 3 chars138 │ │ │ │ │ S103 = via SWIFT MT103, NTRF = non-SWIFT transfer,139 │ │ │ │ │ NMSC = misc, NCHK = cheque, NDDT = direct debit...140 │ │ │ │ └─ amount: max 15 digits, COMMA as decimal separator,141 │ │ │ │ no thousands separators, ALWAYS UNSIGNED142 │ │ │ └─ funds code (optional, 3rd char of currency)143 │ │ └─ debit/credit mark: D | C | RD (reversal of debit) | RC (reversal of credit)144 │ └─ entry (booking) date MMDD (optional; year inferred from value date)145 └─ value date YYMMDD146```147148Key semantics:149150- **Amount is unsigned; the D/C mark gives direction** (D = debit = money out,151 C = credit = money in; `RD`/`RC` mark reversals).152- **Decimal separator is a comma** (`1150,00`), never a dot; the currency is NOT153 on the `:61:` line — it comes from the `:60F:`/`:62F:` balance lines.154- Value date is `YYMMDD` (2-digit year → pivot logic needed); entry date is155 `MMDD` with the year inferred from the value date (beware year boundaries).156- The customer reference (`16x`) is the counterpart of camt's `EndToEndId`, but157 is often `NONREF`; the free-text `:86:` line then carries the useful158 description (bank-proprietary sub-formats exist inside `:86:`, e.g. German159 `/GVC/` and `?20`-style subtags — treat `:86:` as opaque text in v1).160- Integrity check available to the parser:161 `:60F: balance ± Σ(:61: lines) = :62F: balance` — AIR should verify this.162163Sources: Paiementor MT940 detailed analysis, National Bank of Canada MT940 user164guide, Citi MT940 export guide, Huntington developer portal (URLs in §7).165166---167168## 3. Adoption status: camt.053 vs MT940 (MT→MX migration)169170- **22 November 2025**: SWIFT ended MT/ISO 20022 coexistence for cross-border171 *payment instruction* messages (MT103/MT202 retired for FI-to-FI traffic).172- **Cash-management / reporting messages (MT9xx) got an extended timeline**:173 MT940/MT942/MT950/MT900/MT910 are *deprecated and no longer maintained* by174 SWIFT but not yet withdrawn; their removal in favour of175 camt.052/camt.053/camt.054 is being phased in roughly **2027–2028**, and major176 banks tell clients they must be able to *receive* camt messages by177 **November 2027**.178- Practical consequence (2026): **both formats are current reality.** camt.053179 is the strategic/current standard; MT940 remains the most widely deployed180 corporate statement format worldwide (bank portals, ERP integrations, EBICS).181 → AIR must parse **both**, normalizing into one internal model (§6).182183Sources: SWIFT ISO 20022 programme pages, J.P. Morgan and Citi migration FAQs,184RedCompass Labs 2026 deadline analysis, PaymentExpert on the Nov-2025 cutover185(URLs in §7).186187---188189## 4. Bank reconciliation matching practice190191How mainstream systems match statement lines to ledger (book) cash entries:192193- **Exact match first**: same amount, same currency, same/near date. This is the194 universal baseline (QuickBooks Online "matches", Xero "suggested matches").195- **Date tolerance windows**: book date and bank date rarely coincide (cheques196 clear days later; card settlements lag 1–3 days). Treasury/ERP tools (e.g.197 Oracle Fusion reconciliation) expose *configurable* date tolerance rules;198 date tolerances exist mainly for instruments with clearing lag.199- **Amount tolerance**: used for FX rounding differences or bank fees embedded in200 the statement line. QuickBooks does **not** natively do tolerance-based201 matching; Oracle-class treasury tools do (with a write-off/adjustment posting202 for the difference). Xero handles the fee case via "adjustments" during203 reconciliation.204- **Reference matching**: strongest deterministic signal — cheque number,205 invoice number in remittance text, and in camt.053 the `EndToEndId` /206 `AcctSvcrRef`. Xero bank rules can condition on bank text fields, direction207 ("Received"/"Spent") and amount; a rule sets contact/account/tax code.208- **One-to-many / many-to-one (batch) matching**: one bank deposit = many209 customer receipts (or one payroll debit = many payslips). Xero supports210 "Match > multiple items"; QuickBooks Online is weak here natively; camt.053211 expresses it structurally (`NtryDtls/Btch` + several `TxDtls`). Treasury212 reconciliation engines support 1:1, 1:n, n:1 and n:m rule tiers, applied in213 priority order (exact reference → exact amount+date → amount+date window →214 aggregate/batch), each with confidence scoring.215- **Output convention**: after matching, both sides' residues are reported —216 unmatched statement lines (bank has it, books don't: missing entry / fee /217 fraud) and unmatched ledger entries (books have it, bank doesn't: outstanding218 cheque / deposit in transit). This two-sided exception report *is* the219 classical bank reconciliation statement.220221Sources: Oracle Fusion tolerance-rule docs, Xero reconciliation guides,222QuickBooks Online reconciliation guides (URLs in §7).223224---225226## 5. Aggregator APIs (future ingestion frontends)227228### 5.1 Plaid (`/transactions/sync`, `/transactions/get`)229230JSON transaction objects; key fields:231232- `amount` — decimal number. **Sign convention (Plaid docs): "Positive values233 when money moves out of the account; negative values when money moves in."**234 I.e. a debit-card purchase is **positive**, a deposit/refund is **negative**235 — the *inverse* of a naive signed-bank-balance convention. Two decimal places.236- `iso_currency_code` (ISO 4217; null when `unofficial_currency_code` is used).237- `date` (YYYY-MM-DD; posting date for posted transactions, occurrence date for238 pending), plus `authorized_date` / `datetime` / `authorized_datetime`.239- `name` (raw description) and `merchant_name` (Plaid-enriched, cleaner).240- `pending` (bool — details may change at settlement; the posted transaction241 arrives with a new `transaction_id` and a `pending_transaction_id` link).242- `transaction_id` (unique, case-sensitive), `payment_channel`243 (`online` / `in store` / `other`), `personal_finance_category`.244245⚠ Plaid delivers `amount` as a JSON **number** → the AIR parser must decode it246via decimal-preserving parsing (e.g. `json.loads(..., parse_float=Decimal)`),247never through binary floats.248249### 5.2 Flinks (Canadian aggregator, `/GetAccountsDetail`)250251Transactions array per account; each item:252253```json254{255 "Date": "2025-01-31",256 "Code": null,257 "Description": "PAYROLL - Stripe Paycheck",258 "Debit": 1000.4,259 "Credit": 1500.25,260 "Balance": 5105.6,261 "Id": "94584aed-7c98-42a4-9836-9f8557db63f5"262}263```264265- Direction is expressed by **separate `Debit` / `Credit` fields** (one266 populated, the other null in real responses), not a signed amount — a third267 sign convention to normalize. `Balance` is the running balance after the268 transaction; `Id` is Flinks' unique transaction id.269- Same JSON-number caveat as Plaid: parse into Decimal, never float.270271Sources: Plaid Transactions API reference, Flinks GetAccountsDetail docs272(URLs in §7).273274---275276## 6. Example fixtures (small, structurally correct)277278Both fixtures describe the same statement: CAD account, opening balance27925,000.00, one outgoing supplier payment of 1,150.00 on 2026-08-01, one280incoming customer payment of 3,449.93 on 2026-08-04, closing balance 27,299.93281(25,000.00 − 1,150.00 + 3,449.93 = 27,299.93 ✓).282283### 6.1 camt.053 (version 053.001.02)284285```xml286<?xml version="1.0" encoding="UTF-8"?>287<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02">288 <BkToCstmrStmt>289 <GrpHdr>290 <MsgId>AIR-STMT-20260805-001</MsgId>291 <CreDtTm>2026-08-05T06:00:00</CreDtTm>292 </GrpHdr>293 <Stmt>294 <Id>STMT-2026-0151</Id>295 <ElctrncSeqNb>151</ElctrncSeqNb>296 <CreDtTm>2026-08-05T06:00:00</CreDtTm>297 <Acct>298 <Id><Othr><Id>00112233445</Id></Othr></Id>299 <Ccy>CAD</Ccy>300 </Acct>301 <Bal>302 <Tp><CdOrPrtry><Cd>OPBD</Cd></CdOrPrtry></Tp>303 <Amt Ccy="CAD">25000.00</Amt>304 <CdtDbtInd>CRDT</CdtDbtInd>305 <Dt><Dt>2026-07-31</Dt></Dt>306 </Bal>307 <Bal>308 <Tp><CdOrPrtry><Cd>CLBD</Cd></CdOrPrtry></Tp>309 <Amt Ccy="CAD">27299.93</Amt>310 <CdtDbtInd>CRDT</CdtDbtInd>311 <Dt><Dt>2026-08-04</Dt></Dt>312 </Bal>313 <Ntry>314 <NtryRef>BKREF001</NtryRef>315 <Amt Ccy="CAD">1150.00</Amt>316 <CdtDbtInd>DBIT</CdtDbtInd>317 <Sts>BOOK</Sts>318 <BookgDt><Dt>2026-08-01</Dt></BookgDt>319 <ValDt><Dt>2026-08-01</Dt></ValDt>320 <BkTxCd><Prtry><Cd>NTRF</Cd></Prtry></BkTxCd>321 <NtryDtls>322 <TxDtls>323 <Refs><EndToEndId>INV-2026-0042</EndToEndId></Refs>324 <RmtInf><Ustrd>PAYMENT ACME INC INVOICE INV-2026-0042</Ustrd></RmtInf>325 </TxDtls>326 </NtryDtls>327 <AddtlNtryInf>Supplier payment Acme Inc.</AddtlNtryInf>328 </Ntry>329 <Ntry>330 <NtryRef>BKREF002</NtryRef>331 <Amt Ccy="CAD">3449.93</Amt>332 <CdtDbtInd>CRDT</CdtDbtInd>333 <Sts>BOOK</Sts>334 <BookgDt><Dt>2026-08-04</Dt></BookgDt>335 <ValDt><Dt>2026-08-04</Dt></ValDt>336 <BkTxCd><Prtry><Cd>NTRF</Cd></Prtry></BkTxCd>337 <NtryDtls>338 <TxDtls>339 <Refs><EndToEndId>E2E-SALE-7781</EndToEndId></Refs>340 <RmtInf><Ustrd>CUSTOMER CUST 123 SALE 7781</Ustrd></RmtInf>341 </TxDtls>342 </NtryDtls>343 <AddtlNtryInf>Customer payment, sale 7781</AddtlNtryInf>344 </Ntry>345 </Stmt>346 </BkToCstmrStmt>347</Document>348```349350(For `.08+` fixtures the only mechanical change in these fields is351`<Sts><Cd>BOOK</Cd></Sts>` and the namespace suffix.)352353### 6.2 MT940354355```356:20:AIR-STMT-0805357:25:BOFCCAM2/00112233445358:28C:151/1359:60F:C260731CAD25000,00360:61:2608010801D1150,00NTRFINV-2026-0042//BKREF001361:86:PAYMENT ACME INC INVOICE INV-2026-0042362:61:2608040804C3449,93NTRFE2E-SALE-7781//BKREF002363:86:CUSTOMER CUST 123 SALE 7781364:62F:C260804CAD27299,93365```366367Reading `:61:2608010801D1150,00NTRFINV-2026-0042//BKREF001`:368value date `260801` (2026-08-01), entry date `0801`, `D` = debit, amount369`1150,00` (comma decimal), transaction type `NTRF`, customer reference370`INV-2026-0042`, bank reference `BKREF001`.371372---373374## 7. Design decisions for AIR3753761. **Common internal model.** Both parsers (and future Plaid/Flinks ingesters)377 produce the same `BankTransaction`:378 - `date` (booking date, ISO date; value date kept separately if present)379 - `amount` — **signed decimal serialized as a string** (positive = money in380 to the account, negative = money out; AIR convention, normalized from381 CdtDbtInd / D-C mark / Plaid inverse sign / Flinks Debit-Credit columns)382 - `currency` (ISO 4217; from `Amt@Ccy` in camt, from `:60F:` in MT940)383 - `description` (from `AddtlNtryInf`/`RmtInf/Ustrd` or `:86:`)384 - `reference` (from `EndToEndId` / `NtryRef` / `:61:` customer+bank refs;385 `NONREF` normalized to null)386 - plus provenance: source format, statement id, raw line/entry.3872. **Amounts are never floats.** camt/MT940 amounts are parsed from text into388 `Decimal`; MT940 comma decimals converted textually (`1150,00` → `1150.00`);389 aggregator JSON parsed with `parse_float=Decimal`.3903. **Statement integrity check at parse time**: opening balance + Σ signed391 entries must equal closing balance (`:60F:`/`:62F:`, `OPBD`/`CLBD`);392 mismatch is a compiler-grade diagnostic, not a warning.3934. **Matching algorithm (v1)**: match = **amount + currency exact**, with a394 **configurable date tolerance window** (default e.g. ±3 days, policy-driven395 via ALSL, never hard-coded); reference/`EndToEndId` equality is used first396 as a higher-priority deterministic tier and as a tie-breaker when several397 candidates share amount+date. One-to-many (batch) matching deferred to a398 later iteration but the model keeps `TxDtls` multiplicity so it stays possible.3995. **Two-sided residue reporting**: the reconciliation result lists matched400 pairs *and* unmatched items on both sides (unmatched bank lines, unmatched401 ledger entries), mirroring standard reconciliation-statement practice.4026. **Version-tolerant camt parser**: read the namespace to detect the version,403 target the stable core (§1.2), handle the `.02` vs `.08` `Sts` shape.4047. **Both formats are required** (§3): camt.053 is strategic, MT940 remains405 ubiquitous until at least 2027-2028.406407---408409## 8. Sources (all consulted 2026-08-05)410411### camt.053 / ISO 20022412- ISO 20022 MDR Part 2 — Bank-to-Customer Cash Management (iso20022.org): https://www.iso20022.org/sites/default/files/2020-12/ISO20022_MDRPart2_BankToCustomerCashManagement_2020_2021_v1_ForSEGReview.pdf413- Payments Canada — Usage Guideline camt.053.001.08: https://www.payments.ca/sites/default/files/Bank%20to%20customer%20statement%20V08%20(camt.053.001.08)(pdf).pdf414- Nordea — camt.053.001.02 Account Statement Standard: https://www.nordea.com/en/doc/caar-camt-053-001-02-account-statement-standard.pdf415- Betaalvereniging Nederland — IG Bank-to-Customer Statement camt.053: https://www.betaalvereniging.nl/wp-content/uploads/2026/03/IG-Bank-to-Customer-Statement-CAMT-053-v1-1.pdf416- ValidateFin — Reading a camt.053 bank statement: https://validatefin.com/en/blog/camt053-bank-statement417- darko-mijic — iso-20022-camt-053-parser spec: https://github.com/darko-mijic/iso-20022-camt-053-parser/blob/main/docs/iso20022-camt-053-spec.md418- Huntington Developer Portal — CAMT.053: https://developer.huntington.com/enterprisepayments/docs/camt053419420### MT940421- Paiementor — SWIFT MT940 Customer Statement detailed analysis: https://www.paiementor.com/swift-mt940-customer-statement-detailed-analysis/422- National Bank of Canada — MT940/MT101 user guide: https://www.nbc.ca/content/dam/bnc/outils-apps/entreprises/guides/user-guide-mt940-mt101.pdf423- Citi Handlowy — SWIFT MT940 Export User Guide: https://www.citibank.pl/poland/files/SWIFT_MT940_Export_User_Guide_EN.pdf424- Huntington Developer Portal — SWIFT MT940: https://developer.huntington.com/enterprisepayments/docs/swift-mt-940425- Danske Bank — MT940 with structured :86: https://danskeci.com/-/media/pdf/danskeci-com/swift-mt/reconciliation/mt940_structured.pdf426427### MT → MX migration428- SWIFT — ISO 20022 for Financial Institutions: https://www.swift.com/standards/iso-20022/iso-20022-financial-institutions-focus-payments-instructions429- J.P. Morgan — ISO 20022 Migration guidance: https://www.jpmorgan.com/insights/payments/fx-cross-border/iso-20022-migration430- Citi — ISO 20022 Migration FAQ: https://www.citibank.com/tts/sa/iso-20022-migration/assets/docs/ISO-20022-FAQs.pdf431- RedCompass Labs — ISO 20022 deadlines in 2026 onward: https://www.redcompasslabs.com/insights/what-now-iso-20022-deadlines-in-2026-onwards/432- PaymentExpert — Swift's ISO 20022 cutover (Nov 2025): https://paymentexpert.com/2025/11/21/swifts-iso-20022-cutover-the-end-of-mt-and-a-20-year-promise/433- ING — FAQ Swift ISO 20022: https://www.ingwb.com/en/service/payments-and-collections/swift-iso20022/faq-swift-iso-20022434435### Reconciliation practice436- Oracle Fusion Cloud Financials — Overview of Tolerance Rules: https://docs.oracle.com/en/cloud/saas/financials/25d/fairp/overview-of-tolerance-rules.html437- FHP Accounting — Xero bank reconciliation rules & cash coding: https://fhpaccounting.co.uk/xero-bank-reconciliation-like-a-pro-master-rules-cash-coding-and-error-prevention-techniques/438- The IQ Suite — Bank reconciliation in QuickBooks Online / Xero guides: https://bankreconciler.app/blogQuickBooksReconciliation , https://bankreconciler.app/blogXeroReconciliation439440### Aggregator APIs441- Plaid — Transactions API reference: https://plaid.com/docs/api/products/transactions/442- Flinks — /GetAccountsDetail: https://docs.flinks.com/api/connect/endpoints/account-linking/get-accounts-detail443- Flinks — Data types in GetAccountsDetail: https://help.flinks.com/support/solutions/articles/43000705311-data-types-in-getaccountsdetail444445---446447*End of research note — AIR project — Simon-Pierre Boucher — contact@spboucher.ai*448