Stop Calling Them All 'Bank Feeds': The 3 Tiers of D365 Banking Architecture

I had a coffee with a National Practice Lead last week. Smart guy. Runs a massive Dynamics 365 practice.

He asked me: “Justin, why do I need Demiton? We already use [Redacted Global ISV] for payments and [Redacted Aggregator] for feeds. Aren't you just doing the same thing?”

It made me realize that the market uses the term "Banking Integration" as a bucket for three completely different architectures.

If you are a Solution Architect or a CFO, you need to understand that not all banking apps are built the same. They fall into three distinct tiers of maturity, and more importantly, Risk.

Here is the taxonomy.

---

Tier 1: The Readers (Feed Aggregators)

• The Players: SISS (ACSISS), Yodlee, "Bank Feeds" extensions.
• The Architecture: Inbound Only.
• The Function: They fetch statement data (DR/CR) and push it into your Bank Reconciliation journal.

The Verdict: These tools are excellent at what they do: Reading. If all you need is to see what happened in your bank account yesterday, they are perfect.

The Risk:

1. They cannot move money. You still have to export a payment file to your desktop and manually upload it to the bank. The "Alt-Tab" vulnerability remains open.
2. Regulatory Pressure: Many legacy aggregators rely on Screen Scraping (storing your internet banking password and logging in as you). The Australian Treasury is actively moving to ban this practice in favor of CDR (Consumer Data Right). If your feed provider relies on scraping, you are building on a burning platform.

---

Tier 2: The Relays (Global ISVs)

• The Players: The big European/US Payment Automation suites.
• The Architecture: Cloud Relay (Store & Forward).
• The Function: They handle the workflow inside Business Central (Approvals, OCR) and generate the payment file.

The Verdict: Great for workflow, dangerous for sovereignty.

The Risk: To convert your payment data into a format the bank understands (e.g., ABA or ISO20022), many global ISVs send your data out of Business Central and into their own cloud servers for processing.

Often, those servers are in Europe or the US.

For an Australian Government agency, Health provider, or Defence contractor, sending vendor banking details to a foreign jurisdiction for processing is a Data Sovereignty Breach.

You might have "Data Residency" for Dynamics 365 in Australia, but if your payment pipe routes through Denmark to generate the file, you have broken the chain.

---

Tier 3: The Iron Layer (Sovereign Infrastructure)

• The Players: Demiton.
• The Architecture: Bi-Directional, RAM-Only Tunnel.
• The Function: We don't just "Read" or "Relay." We Orchestrate.

The Difference: We built Demiton specifically to close the gaps left by Tiers 1 and 2.

1. Bi-Directional: We handle the Outbound (Payment Files) and the Inbound (Acks, Dishonours, and Statements). It is a closed loop.
2. Ghost Protocol: We do not "Store and Forward." We stream data from D365 to the Bank via Volatile Memory (RAM). The payload is never persisted to a disk unencrypted.
3. Sovereign Compliance: The entire process happens inside Azure Australia East. Your data never leaves the country.
4. Protocol Zero: We encrypt payloads using PGP (AES-256) and route them via a Static IP (Cloud NAT) to satisfy strict bank firewalls (NAB Direct Link / CommBiz).

---

Summary: Choose Your Risk Profile

• If you just want to see your bank balance: Use an Aggregator (Tier 1).
• If you want AP automation but don't care about Data Sovereignty: Use a Global ISV (Tier 2).
• If you want Liability Immunity and a secure, sovereign pipe for your capital: You need the Iron Layer (Tier 3).

Stop treating "Banking" as a checkbox feature. It is critical infrastructure.

Explore the Architecture →