Your bank, your aggregator, your Business Central.
Balances, statements, reconciliation and payments — straight through BC via the open-banking aggregator of your choice. Six providers shipped. Pick a different one per bank account. Switch anytime. No vendor lock-in.
- 6 aggregators: Ponto · TrueLayer · Lean · Plaid · Setu · Basiq
- AIS + PIS in EU / UK / GCC · file fallback in US / IN / AU
- Rules first · Claude second · human accepts every match
- Confirmation of Payee hard-gates every payment
- Cash Position dashboard · FX-converted totals
- Standalone (dependencies: []) · insert-only audit
Where Direct Banking shows up for the people who use it
Connect · Test · Change provider
Accept · Reject · Investigate
Send via Direct Banking · CoP
Cash Position · Cash Cues
Residual matcher · rationale · accept
Open banking exists. Business Central still runs on file uploads.
Every serious European, UK, GCC and increasingly US and Australian bank now speaks a real API. Meanwhile finance teams on Business Central are still downloading MT940 files from a portal, uploading them to BC, exporting NACHA / SEPA files, uploading those back to a portal, keying in the acknowledgement, and reconciling by hand. Direct Banking closes that loop — the aggregator of your choice pulls balances and transactions live, rules and Claude do most of the reconciliation, payments go out with Confirmation of Payee. And because the aggregator is your choice per bank account, you never trade one file-upload lock-in for a different SaaS lock-in.
Ponto, TrueLayer, Lean, Plaid, Setu, Basiq. Different provider per bank account. Switch anytime. Sibling connectors plug in through the SFD IBanking Provider interface.
Licence Guard, Country Guard, Provider Capability. Nothing surfaces that your licence and region cannot support. Least-privilege OAuth scopes at consent time.
app.json declares no required AppSource dependency. Sits alongside standard BC and any other extensions you run. Upgrade-safe by construction.
Retrieve. Reconcile. Pay. See.
Direct Banking runs the four stages of a bank interaction end-to-end inside Business Central. Every stage lands in the same journals and same audit tables your finance team already knows.
A background Job Queue asks each connected aggregator for the latest transactions on each bank account. Rows land in a proprietary staging table with a provider transaction-id and a SHA-256 content hash — duplicates are refused idempotently, so re-running a sync is always safe. Balances update the Bank Account card in place.
- Job Queue per bank account, run at your cadence
- Idempotent dedup: provider txn-id + SHA-256 of date | amount | currency | reference
- Balances updated live on the Bank Account card
- Historic staging kept across provider swaps — no loss on switch
- Least-privilege OAuth scopes: only what your licence entitles
Deterministic Reconciliation Rules run first — text patterns, amount tolerance, dimension-aware, per-account priority. Any lines still unmatched fall through to Claude, which proposes matches with a rationale. Every AI suggestion goes through the same validation as a rule match, and every match — human, rule or AI — waits for a Planner Accept before it hits the ledger.
- SFD Reconciliation Rule tables — priority-ordered per bank
- AI matcher runs only against the residual, not the full statement
- Every AI suggestion validated against BC ledger schema before showing
- Match Entry table keeps a full history of accepted / rejected / overridden
- Reconciliation workspace with one-click Accept / Reject / Investigate
Mark payment journal lines and click Send via Direct Banking. Three guards re-run server-side: licence, country capability, provider capability. Confirmation of Payee checks each vendor account and hard-gates the submission on mismatch — override requires an audited reason. Where the region does not have a PIS framework yet (US, India, Australia), the same button falls back to a NACHA / ABA / CSV file export.
- Server-side three-layer guard: licence · country · provider
- Confirmation of Payee blocks payment on mismatch — override is audited
- Duplicate payment check before submission
- Payment Status Job polls the aggregator until final state
- Fallback exports: NACHA (US), ABA (AU), CSV (generic) — licensable
A Cash Position page and a Cash Cues card-part sit on the Business Manager role centre. Every currency is converted at the current rate; totals are consolidated across all connected accounts and all providers. Finance sees the true cash position in one page — no spreadsheet, no manual FX call, no waiting for reconciliation to close.
- Cash Position page: multi-account, FX-converted totals
- Cash Cues card-part on Business Manager role centre
- Drill-through from any cue back to the underlying account
- Insert-only Activity Log for every action — audit-clean
- Telemetry emits category + outcome only, never free-text
Pick the one that fits your bank. Pick a different one next year.
Six aggregators cover most of the world for AIS (balances and statements). Three of them cover PIS (payments). Regions without a PIS aggregator yet fall back to a NACHA / ABA / CSV file export — same button, same journal.
Ponto
EU · UK · GCC
Isabel Group's aggregator for European corporate banking. Broad EU coverage, mature PIS certification.
TrueLayer
EU · UK
UK open-banking pioneer. Strong PIS on UK high-street plus European reach.
Lean
GCC
Gulf-focused aggregator covering UAE, Saudi and Bahrain banks with regulator-approved PIS.
Plaid
USA
The US aggregator standard. AIS live; payments handled through NACHA file fallback until US PIS matures.
Setu
India
India's RBI-licensed Account Aggregator framework. AIS live; UPI / NEFT / IMPS PIS on the roadmap.
Basiq
Australia
Australia's Consumer Data Right leader. AIS live; payments via ABA file fallback.
Eight things finance teams notice from week one.
The features that show up on the day-two demo, in the month-end reconciliation, and in the internal-audit walkthrough.
Provider of your choice
Six aggregators shipped, one interface. Pick a different provider per bank account. Switch providers on any account at any time — statement history is preserved.
Confirmation of Payee
Vendor Bank Account is verified against the payee name at the destination bank. Mismatch hard-gates the payment. Overriding the gate requires a written reason that lands in an insert-only history table.
Idempotent statement import
Every incoming transaction is deduplicated by provider txn-id and by a SHA-256 hash of the content. Re-running a sync is always safe — duplicates are refused, never re-inserted.
Rules first, Claude second
Deterministic rules match what they can. The AI matcher runs only against the residual. Every suggestion is validated before it's shown. Nothing is auto-applied — a planner clicks Accept on every match.
Cash position, FX-converted
One page shows the true consolidated cash position across every connected bank and every currency, at today's rate. Cash Cues on the role centre make the number visible at a glance.
Payment-file fallback
Where the region has no PIS framework (US, India, Australia), the Send action falls back to a NACHA / ABA / CSV export — same button, same journal, no separate workflow to learn.
Insert-only audit
SFD Activity Log is insert-only by permission set and table trigger. Every state change captured. Telemetry emits category and outcome only — never free-text — so nothing sensitive leaks.
Localisation companions
NL and BE localisation companions ship as separate sibling apps — CBG statement layout, EB payment journal — via a Journal Target enum and an OnTransferToLocalJournal event. New locales add without touching the core.
Three places AI proposes. Three places it never touches.
Deterministic rules run first. Claude only sees the residual — the lines rules could not match. Every AI suggestion is validated against the BC ledger schema before it surfaces, so an invalid suggestion never reaches the planner's screen.
What AI is explicitly not allowed to do: accept a match, send a payment, override Confirmation of Payee. The Accept, the Submit and the CoP override are human-only actions. The guard is enforced in the codeunit path, not by convention.
- Match residual statement lines
After rules run, unmatched lines are handed to Claude with the open receivable / payable candidates. Claude proposes matches with a rationale.
- Explain a suggested match
For any AI-suggested match, Claude produces a plain-English rationale — which fields it matched on, which candidates it considered and rejected, why the confidence is what it is.
- Categorise unknown transactions
New merchants / new counterparties get a proposed GL account, tax and dimension set. The planner accepts individually — nothing auto-books.
- Accept a match
No AI suggestion applies itself. Every match — human, rule or AI — waits for a Planner Accept before it hits the ledger.
- Send a payment
The Send button is human-only. Once the three-layer guard passes and CoP clears, the planner clicks Submit. AI never initiates a payment.
- Override Confirmation of Payee
A CoP mismatch can only be overridden by a human with a written reason. The AI cannot skip the gate — the reason field is required by the guard, not by convention.
From aggregator ping to posted GL entry.
One flow that runs every morning against every connected account. Every step is auditable in one place, every AI suggestion is human-approved, every payment goes through Confirmation of Payee.
- 1Job Queue triggers Sync Job for each bank account at 06:00.
- 2Provider adapter calls the aggregator API for balances and transactions.
- 3Statement Import dedups new lines by provider txn-id and content hash.
- 4Reconciliation Engine runs deterministic rules — most lines match here.
- 5Residual lines pass to AI Match Engine; Claude proposes matches with rationale.
- 6Planner opens the Reconciliation Workspace and clicks Accept on the true matches.
- 7Journal Populator writes to the Payment Reconciliation Journal.
- 8Planner posts the journal — standard BC posting path, no parallel ledger.
- 9Payment run: Send via Direct Banking triggers three-layer guard + Confirmation of Payee.
- 10PIS call goes out through the aggregator; Status Job polls until final.
Statement · ING Belgium ──────────────────────────── Lines imported 142 Deduped (already seen) 38 New 104 Rule matches 89 Vendor pattern 42 Customer pattern 31 Tolerance / narrative 16 AI residual matches 11 Confidence >= 0.90 7 Confidence 0.70-0.89 4 Manual required 4 ──────────────────────────── Ready to accept 100 Payment run 12 CoP Match 10 CoP Close Match 2 (warn) CoP Mismatch 0 Submitted via Ponto 12 Final status 10 Pending 2
Six architectural decisions that keep Direct Banking clean.
Each one is enforced — by AppSourceCop, by our own ruleset, or by the guard rails baked into the code paths themselves.
Standalone by architecture
app.json declares zero required dependencies. Every hook into base BC goes through table extensions, page extensions and event subscribers — never a modification. Sibling connectors and localisation packs plug in through interfaces and enums.
Provider-agnostic by interface
SFD IBanking Provider is an interface with an extensible Banking Provider enum. Six providers shipped; adding a seventh is a new codeunit that implements the interface and a new enum entry — no change to the rest of the app.
Three-layer guard on every action
Licence Guard (JWT RS256 verified offline against bcextactivate.com), Country Guard (data-driven capability table per region), Provider Capability probe. Actions are hidden-not-disabled when the guard doesn't clear — upsell hint appears only when the licence is the missing layer.
Least-privilege OAuth
Only the scopes your licence includes are requested. If PIS is not licensed, the OAuth consent screen never asks for payment permission — the customer can't accidentally grant more than they're entitled to.
Secrets in Isolated Storage
Aggregator OAuth tokens and the Anthropic API key live in Isolated Storage under the SFD Token Store. Nothing sensitive appears in a table or a metadata field. Rotation is a one-line operation.
Insert-only history everywhere
Activity Log, Match Entry, Payment Buffer, Verification History and CoP Override Reason are all insert-only. Audit can walk from any ledger entry back to the exact bank transaction and every human decision that took it there.
4–6 weeks for a single entity. One extra week per additional bank account.
Implementation scales with the number of banks and aggregators, not the number of employees. A single-entity single-bank pilot is the fast path. Multi-entity, multi-region deployments add time for consent, rules authoring and CoP override workshopping — not for engineering.
Per-Tenant Extension while AppSource clears. Same code, same license.
Week 1
Bank list agreed. Aggregator per bank account decided (Ponto for the Belgian bank, Plaid for the US bank, Setu for the India bank, etc). Licence tier and country entitlements confirmed. Assisted-setup wizard run in a sandbox tenant.
Week 2
Each bank account authorised through the aggregator's hosted consent flow. Confirmation of Payee enabled per bank. Reconciliation rules imported from an existing spreadsheet or authored fresh from the last 90 days of statements.
Weeks 3–4
One entity, one week of live statements, one payment run. Rules tuned, Claude confidence thresholds set per bank, CoP override reasons workshopped with finance. Cash Cues activated on the role centre.
Week 5
All entities on Direct Banking. Legacy MT940 downloads and NACHA uploads retired. Payment file fallback enabled for US / IN / AU bank accounts. Activity Log reporting handed to internal audit.
Week 6+
Daily automated sync, weekly payment run, month-end reconciliation completes in an hour instead of a day. Rules library grows as new patterns land. Provider swaps happen on demand — one account at a time.
Beyond
Add the NL or BE localisation companion for CBG statements and EB payment journals. Add a Phase-2 aggregator (Tink / Salt Edge, Yapily, MX / Finicity) as those certifications complete. Enable cash-flow forecasting when the module ships.
Frequently asked questions
Six shipped in v1: Ponto (EU / UK / GCC), TrueLayer (EU / UK), Lean (GCC), Plaid (US), Setu (India), Basiq (Australia). Ponto, TrueLayer and Lean support both AIS (balances / statements) and PIS (payments). Plaid, Setu and Basiq are AIS today; payments for those regions fall back to NACHA / ABA / CSV file exports. Phase-2 aggregators (Tink / Salt Edge, Yapily, MX / Finicity, Finvu / Perfios, Frollo / Adatree) are on the roadmap.
Bring one bank. We'll connect it live and reconcile a real week.
A 60-minute working session, not a slide deck. Pick one of your bank accounts, tell us which aggregator you want to try, we install Direct Banking in a BC sandbox, run the consent flow live, pull the last week's statements, run rules-then-Claude reconciliation, and walk through the Accept queue with you.
- Live install + aggregator consent in your BC sandbox
- Your real statement · reconciled end-to-end
- Honest advice on which aggregators fit your bank list
- Written proposal within one working day