The short answer
In banking and insurance, Dynamics 365 is rarely the system of record for accounts or policies. It is the place where the activity of those systems becomes controlled accounting, joined-up customer service, governed payments, regulatory reporting and workflow. The core stays. The integration is what turns it into a business advantage.
Banks, lenders, insurers, brokers and microfinance institutions share a pattern: a core system that is excellent at its narrow job, surrounded by spreadsheets, e-mail approvals and reconciliations that grow with every product. This guide maps the integration use cases that matter across the whole value chain, from the general ledger to the customer conversation, so you can see the full picture and choose where to begin.
We group them in four families: the finance backbone, customers and distribution, people and operations, and data, AI and control. For each use case we say what is integrated, which Microsoft components carry it, and what you gain. We also say what should not go into Dynamics 365. Capabilities and regulations change, and the right design depends on your licence, your regulator and your core systems, so treat this as a map for the first workshop, not a specification.
The reference architecture
Almost every use case below is a variation on one shape. Understanding it makes the rest simple.
- Core systems stay where they are: core banking, lending, deposits, treasury, policy administration, claims, actuarial and reinsurance engines, card and payment switches.
- Azure integration brings activity in and out: APIs, events, queues and scheduled files, with retries, throttling, logging and alerting designed in. See Azure, data and integration.
- Dynamics 365 Finance holds the general ledger, consolidation, payables, receivables, fixed assets and controls; Dynamics 365 Sales and Customer Service hold the relationship and the case. See Finance and Operations.
- Power Platform carries approvals, exceptions and small applications; Power BI and Microsoft Fabric carry reporting and the data foundation. See Power Platform and Power BI.
- Microsoft 365, Teams and Entra ID put the work where people already are, under one identity.
The rule that keeps the design healthy: each fact has one owner. A loan balance belongs to the lending system, a posted entry to the ledger, a customer conversation to the service case. Integration moves summaries and references between them, with a traceable link back to the source.
Family one: the finance backbone
This is where banks and insurers feel the pain first, and where the return is easiest to defend.
| Use case | What is integrated | Microsoft components | What you gain |
|---|---|---|---|
| 1. Sub-ledger to general ledger | Core banking, lending, deposit and insurance activity summarised into journals | Azure integration, Dynamics 365 Finance, AccountingFlow 365 | One rule-based posting engine, audit trail to each source transaction |
| 2. Regulatory classification at posting | Product, entity and transaction type mapped to reporting categories such as IFRS 18 | Posting rules, financial dimensions, financial reporting | Classification arrives in the ledger on day one, not rebuilt at quarter-end |
| 3. Multi-entity and multi-currency close | Group entities, intercompany, consolidation | Dynamics 365 Finance consolidation | A faster, evidenced group close |
| 4. Governed outbound payments | Claims payouts, commissions, vendor and employee payments | DisbursementFlow 365, ISO 20022 files | Maker-checker control and one gateway to many banks |
| 5. Reconciliation and exceptions | Bank, nostro, premium, settlement and sub-ledger tie-outs | Power Automate, Dynamics 365 Finance, Copilot summaries | Exceptions routed to a person with the evidence, not found in a spreadsheet |
| 6. Tax and e-invoicing at posting | Tax authority systems by country | DigiTaxFlow 365 | Invoices signed and submitted as they post |
| 7. Lease and fixed-asset accounting | Branch, vehicle, equipment and premises leases | LeasingFlow 365, fixed assets | IFRS 16 schedules inside the ledger |
| 8. Procurement and vendor control | Requisition to payment, third-party onboarding | Dynamics 365 procurement, approvals in Teams | Spend under control, evidence for audit |
| 9. Regulatory and management reporting | Ledger, sub-ledger and operational data | Power BI, Microsoft Fabric | One data set for the board pack and the regulator |
Use case 1 is the anchor. Banks and insurers produce millions of transactions that have to be summarised into journals. If a person assigns the account or the reporting category at month end, it will be late and inconsistent. A rule-based accounting hub puts the decision in one place and keeps the trail to every source transaction. We describe this in detail in IFRS 18 in Dynamics 365 Finance.
Insurers should note one boundary: actuarial, reserving and reinsurance calculation engines stay as specialist systems. Dynamics 365 receives their results as journals and carries the controls, the entity structure and the reporting, rather than replacing the calculation.
Family two: customers and distribution
Dynamics 365 began as a customer platform, and in financial services it is often where the front office is joined up.
| Use case | What is integrated | Microsoft components | What you gain |
|---|---|---|---|
| 10. Customer 360 | Accounts, policies, interactions and consents from core and channel systems | Azure, Dataverse, Customer Insights | One view for staff, built from the systems that own the facts |
| 11. Onboarding and KYC case flow | Application, documents, screening results from your chosen providers | Power Automate, Dataverse, Dynamics 365 Sales | A tracked, auditable onboarding case, with exceptions escalated |
| 12. Relationship management | Corporate and commercial clients, pipelines, credit-committee preparation | Dynamics 365 Sales | Relationship managers work from live exposure and activity |
| 13. Broker and agent management | Distribution partners, licensing, commissions, performance | Dynamics 365 Sales, Finance payables | One record from partner onboarding to commission payment |
| 14. Service and complaints | Enquiries, disputes and complaints with response clocks | Dynamics 365 Customer Service, Digital Contact Center | Cases with deadlines, ownership and an audit trail |
| 15. Claims intake and tracking | First notice of loss, documents, status updates | Dynamics 365 Customer Service, Power Apps, claims system integration | Claimants kept informed; the claims engine still decides |
| 16. Policy and account servicing | Change requests, endorsements, address and beneficiary updates | Power Apps, Power Automate | Requests tracked end to end, then posted to the core |
| 17. Consent-led marketing | Segments, journeys and consent records | Customer Insights | Relevant outreach that respects consent |
Two cautions. First, the customer record is not a copy of the core database. It is a view assembled from the owners of each fact, with references back. Second, screening, scoring and decisioning stay with the specialist providers and engines you already use. Dynamics 365 coordinates the case, the evidence and the people around them.
Family three: people and operations
The back office of a financial institution is large, regulated and full of approvals.
- 18. People and payroll: recruitment, core HR, performance, learning, pay and benefits, recognition, with payroll posting to the ledger. See HumanResourcesFlow 365 and PayrollFlow 365.
- 19. Approvals where people work: payment releases, journal approvals, limit exceptions and policy attestations routed through Teams and Outlook with the evidence attached.
- 20. Contracts, outsourcing and third-party risk: supplier onboarding, due diligence tasks, renewals and service-level reviews, tracked in one place.
- 21. Branch and shared-service operations: requests, expenses and small applications built on Power Platform rather than e-mail and spreadsheets.
- 22. Project and programme delivery: regulatory and change programmes tracked in Dynamics 365 with budgets tied to the ledger.
Family four: data, AI and control
This is where the Microsoft platform adds the most beyond any single application.
| Use case | What it does | Microsoft components | Guardrail |
|---|---|---|---|
| 23. One governed data foundation | Lands ledger, sub-ledger and operational data for reporting and models | Microsoft Fabric, Azure data services, Power BI | Lineage and access control defined before dashboards |
| 24. Copilot and agents for finance | Summarises exceptions, drafts reconciliations and explains variances | Copilot in Dynamics 365, agents | A person approves every posting and payment |
| 25. Alert and case triage | Alerts from monitoring or fraud tools become cases with owners and deadlines | Power Automate, Dataverse, Customer Service | Decisions remain with your risk systems and teams |
| 26. Controls and audit evidence | Segregation of duties, approval limits, change logs, immutable status logs | Security roles, Entra ID, audit features | Control design agreed with internal audit |
| 27. Identity and access | One sign-in, conditional access, joiner-mover-leaver | Microsoft Entra ID | Role matrix tested in user acceptance |
| 28. Resilience and monitoring | Interface health, retries, alerting, backup and recovery | Azure monitoring, environment management | Named owner for every interface |
Agents deserve a note of realism. They earn their keep on bounded, high-volume work such as summarising an exception queue or preparing a reconciliation, with a person approving the outcome. We set out where they fit and where they do not in Agentic ERP without the hype.
Banking: where each use case lands
A bank or lender rarely adopts all of these at once. The usual order follows the pain.
| Bank, lender or microfinance | Typical starting point | Next |
|---|---|---|
| Retail and commercial bank | Sub-ledger to ledger and reconciliation (1, 5) | Payments (4), reporting (9), customer 360 (10) |
| Lender or microfinance institution | Loan and deposit postings (1), disbursements (4) | Onboarding case flow (11), service and complaints (14) |
| SACCO or cooperative | Member and share accounting (1), payments (4) | Member service (14), HR and payroll (18) |
| Corporate and investment banking unit | Relationship management (12), reporting (9) | Onboarding (11), approvals (19) |
The common thread is the same: begin where manual work is largest and the control is weakest, usually the bridge between the core system and the ledger.
Insurance: where each use case lands
Insurers add premium, claims and distribution flows, and often a group structure with several entities and currencies.
| Insurer, broker or reinsurance entity | Typical starting point | Next |
|---|---|---|
| General or life insurer | Premium, claims and commission postings (1), classification (2) | Claims intake (15), policy servicing (16) |
| Broker or intermediary | Client money and commission accounting (4, 13) | Relationship management (12), complaints (14) |
| Group with several entities | Multi-entity close (3), reporting (9) | Data foundation (23), controls (26) |
| Health or takaful operator | Claims payouts (4), member service (14) | Consent-led outreach (17), approvals (19) |
Reinsurance, reserving and actuarial calculation stay in their specialist engines. The integration carries their results into the ledger with the trail an auditor expects.
The integration patterns, in plain terms
Choosing the pattern per interface, rather than one pattern for everything, is what keeps the design reliable.
- Real-time API: for lookups that must be current, such as a customer balance shown to a service agent. Design for latency and for the source system being down.
- Events and queues: for things that happen, such as a claim registered or a payment status changed. Decouples systems and supports retries.
- Scheduled batch files: still the norm for end-of-day postings from core systems. Fine when reconciled and monitored.
- Dataverse and virtual tables: show data from another system inside Dynamics 365 without copying it.
- Data platform feeds: land data in Fabric or Azure for reporting and models, without loading operational systems.
Whatever the pattern, four things are non-negotiable: an owner for each interface, error handling and retries, logging that an auditor can follow, and reconciliation between source and target.
What not to put in Dynamics 365
Honesty about boundaries earns trust, and saves money.
- The core ledger of accounts, balances and interest accrual in a bank. That remains the core banking system.
- The policy administration, rating and underwriting engine in an insurer.
- Actuarial, reserving, reinsurance and risk-model calculation.
- Payment switches, card processing and real-time fraud scoring.
- Anything that your regulator requires to be a specific certified system.
Dynamics 365 earns its place around these systems: the ledger, the customer and case record, the approvals, the payments, the reporting and the controls.
A sensible first 90 days
The aim is a result the finance team and the auditor can inspect, not a diagram.
- Weeks 1 to 3, map: list the core systems, the interfaces, the manual bridges and the reconciliations. Rank them by effort and control weakness.
- Weeks 4 to 6, design: choose the first use case, usually the sub-ledger to ledger bridge or the payment gateway. Agree the data owner, the posting rules or approval rules, and the reconciliation.
- Weeks 7 to 10, prove: build the interface for one product line or one entity, run it in parallel with the current process, and reconcile.
- Weeks 11 to 13, decide: show the finance team and audit the evidence, then agree the roll-out order for the next use cases.
A short first release that survives an audit beats a broad one that does not.
Mistakes we see
- Copying the core system into Dynamics 365: duplicates data and creates a reconciliation problem. Link and summarise instead.
- Starting with customer-facing features while the ledger bridge is manual: the visible work looks good and the back office stays slow.
- Treating regulatory classification as a reporting exercise at quarter end rather than a posting decision.
- Ignoring interface ownership: an interface nobody owns fails quietly.
- Putting an agent on an unreconciled process: it speeds up the confusion.
- Skipping role design: segregation of duties is designed against a role matrix, not discovered in user acceptance.
Where to start
Start with a half-day workshop on your core systems, interfaces and month-end. You leave with the use cases ranked for your institution, a reference architecture, the boundaries drawn, and a first release you can defend to finance, audit and your regulator.
See how this looks for your sector on our financial services and insurance page. This article is general information, not legal, regulatory or accounting advice. Confirm product capabilities, licensing and regulatory requirements for your jurisdiction.
Frequently asked questions
What are the main Dynamics 365 integration use cases in banking and insurance?
They fall into four families: the finance backbone (sub-ledger to ledger, classification, consolidation, payments, reconciliation, tax, leases, reporting), customers and distribution (customer view, onboarding cases, relationship management, service and complaints, claims intake), people and operations (HR, payroll, approvals, third-party management) and data, AI and control (data foundation, Copilot and agents, triage, audit evidence, identity and monitoring).
Does Dynamics 365 replace our core banking or policy administration system?
No. Core banking, lending, policy administration, claims, actuarial and reinsurance engines stay where they are. Dynamics 365 turns their activity into controlled accounting, joined-up customer service, governed payments, workflow and reporting.
What is a financial services accounting hub?
It receives sub-ledger activity from core banking, lending and insurance systems and posts it to the general ledger under rule-based posting with an audit trail to the source transactions. Ours is delivered as AccountingFlow 365 on Dynamics 365 Finance.
Which use case should a bank or insurer start with?
Usually the bridge between the core system and the ledger, or the outbound payment gateway, because manual work is largest and control is weakest there. A short first release that survives an audit is better than a broad one that does not.
How does Dynamics 365 integrate with our core systems?
Through Azure integration services and the pattern that fits each interface: real-time APIs, events and queues, scheduled batch files, virtual tables or data platform feeds, with error handling, logging, reconciliation and a named owner for each interface.
Can Copilot and agents be used in finance operations?
Yes, on bounded, high-volume work such as summarising exception queues or preparing reconciliations, with a person approving every posting and payment. They work best on processes that are already reconciled.
What should not be moved into Dynamics 365?
The core ledger of accounts and balances, policy administration and rating, actuarial and reserving engines, payment switches and real-time fraud scoring. Dynamics 365 works around these systems.
How do you handle regulatory reporting such as IFRS?
By deciding the reporting classification at posting, carrying it in the ledger through dimensions and posting rules, and reporting from one data set. Classification policy remains yours and your auditor's.