Banking System Integration With Microsoft: How Do Banks Start?

Somebody just asked for a current data flow diagram between the core and the Microsoft estate, and nobody in the building can produce one that matches what is actually running. That is not unusual. The connective tissue between a bank’s core, its loan origination system and Dynamics 365, Azure and Microsoft 365 was rarely designed as a system; it accumulated, one overnight file drop and one scheduled job at a time, until a batch window that started as a convenience became something the business depends on without anyone deciding it should. This guide is for the VP of IT or IT Director who has to turn that accumulation into a design a bank examiner can be shown, without either under-building the oversight or buying an integration platform to move four files a night.

The failure that shows up in an exam is rarely the integration that broke; it is the one where two systems both hold a balance and neither is named as the book of record. A core banking platform, a loan origination system bought on its own timeline, and a Microsoft estate that grew underneath both of them arrive at the same moment a batch job somebody wrote years ago is still the only thing moving data between them, and nobody currently at the bank remembers why it runs at 2 a.m. instead of on demand. Each addition solved a problem in the moment: a spreadsheet became a nightly export, the export became a scheduled task, the scheduled task became load-bearing. None of that is a mechanism failure. It is the absence of a mechanism, which is a different problem and needs a different first move.

The first move is documentation the FFIEC IT Examination Handbook’s Architecture, Infrastructure, and Operations booklet already names as an expectation, not an option: “Data flow diagrams show how the entity’s data flows between critical hardware on the network, not just where a piece of hardware resides,” and the diagram may include “Data sharing between applications” and “Data flow within the entity … and between the entity and its third-party service providers.” A diagram drawn after the fact, from what the batch jobs actually do rather than from what someone remembers designing, is the starting artifact for everything that follows in this guide. The general Microsoft integration methodology that diagram work sits inside, sequencing, discovery, the standard architecture process, is covered in full at System Integration Best Practices for Microsoft Enterprises; this guide starts one level down, at the constraint a bank’s examiner adds on top of that general method.

The question that actually matters is not which tool moves the data; it is which system’s answer is the answer when two systems disagree. Before any integration tool, queue or API is chosen, four decisions belong on paper, because a transport decision made ahead of them just moves the same undocumented accretion onto newer infrastructure.

Decide the book of record for every field before you decide the transport, because an integration that moves a balance between two systems without naming which one is authoritative produces a reconciliation nobody can complete, and the reconciliation, not the transport, is what the examiner asks to see. If Dynamics 365 holds the relationship and servicing view of a customer while the core holds the account of record, the design states that plainly for every shared field, not just for the ones that have already caused a discrepancy.

The reconciliation design belongs alongside the book of record: when two systems disagree, which alert fires, who resolves it, and how long a disagreement is allowed to stand before it is itself a finding. A design with no reconciliation rule is a design that discovers its own gaps only when a customer calls.

What happens on failure and replay is decided before the flow goes live. A file that fails halfway through, a message that is delivered twice, or a batch window that overruns into business hours are not edge cases in a design that runs every night; they are the design’s normal operating conditions, and each needs a stated behavior, not a hope.

Decide what “real time” actually has to mean for each flow, because most flows that get built as real time do not need to be. The FFIEC handbook’s design-objectives list names the aspects a bank’s architecture should account for, among them integrity, “validation checks to promote accuracy,” availability and resilience measured against a stated recovery time and recovery point objective, and interoperability, which the handbook defines for supervisory purposes as “the ability of data, systems, or software to work with or on multiple systems or software.” A flow that only needs to be current by the next business day does not need the operational cost of an always-on integration, and calling it real time anyway is how a working batch job becomes a second system to run and be examined on for no reason.

The pattern that fails an exam is not the wrong one chosen; it is the one chosen without a stated reason, because the reviewer’s first question is why this flow uses this pattern and not another. Three integration patterns cover nearly every flow between a bank’s core, its loan origination system and the Microsoft estate, and the honest answer for most banks is that more than one of the three will be running at the same time, for different flows, on purpose.

Scheduled batch is right when the flow does not need to be current faster than the business actually operates, when the source system has no API to call, or when a core vendor’s contract does not permit direct access at all. The cost is latency and the operational load of monitoring a batch window that, if it silently fails, nobody notices until a downstream report is wrong.

Request and response, a direct API call answered synchronously, is right when a user or a process needs an answer before it can proceed, such as a loan origination system checking a customer’s standing before quoting a rate. It requires the source system to expose an API in the first place, which a core platform frequently does not, and it couples the requester to the responder’s availability in a way a batch job does not.

Event-driven publish and subscribe is right when multiple systems need to react to the same change without querying each other directly, and when the bank wants new consumers added later without touching the systems that produce the event. The FFIEC handbook’s own design objective names this pattern’s underlying property, “loose coupling,” as part of what interoperability and integration are meant to achieve. The event-driven mechanics themselves, the event grid, the trigger design, the retry and replay behavior, are covered in full at Event-Driven Integration on Azure for Regulated Enterprises; what a bank adds on top of that general pattern is the book-of-record rule above and the evidence set below.

The honest case for leaving a working batch job alone belongs here too. A nightly file that reconciles cleanly, that the business has never needed sooner, and that nobody has to re-architect to pass an exam is not a defect; replacing it to look modern is a cost with no risk reduction behind it. The decision criterion is not which pattern is newest. It is which pattern matches what the flow actually needs, stated in writing so the next reviewer, internal or external, can see the reasoning rather than infer it.

The mistake that reads as sophistication and is actually risk is treating the platform as the integration layer, because the platform was never built to be one. Dynamics 365 is an endpoint in this design, the system where relationship and servicing data lives and where a banker or a servicing team works; Microsoft 365 is an endpoint too, where the people are, where a document is reviewed or a decision is recorded. Azure’s integration services are where the governed layer sits between the endpoints and the core and loan origination systems: the place access, logging and change control belong in one location rather than duplicated inside every point-to-point connection. Putting integration logic inside a Dynamics 365 customization because that is where a developer happened to be working is how a platform quietly becomes the transport, with none of the governance a dedicated integration layer was built to provide.

i3solutions has delivered Dynamics 365 integration engagements for regulated enterprises across healthcare, defense and aerospace manufacturing, and financial services. That is a description of the sectors the work has been delivered in, not a claim about any one bank or any specific integration built for one; it is named here because it is the attested fact this page can state about i3solutions’ own Dynamics 365 integration history, and the honest limits of that fact matter as much as the fact itself, covered fully below.

An examiner does not ask whether the integration works; the request is for the evidence that it was designed on purpose and is still being watched, and a bank that can only answer the first half of that has already produced the finding. Five artifacts make up that evidence set, and each is produced from a named source, not assembled the week before the exam.

A current data flow diagram, matching what is actually running, not what was designed at the last major project, showing data sharing between applications and the flows between the bank and its third-party service providers, as the FFIEC handbook’s data flow diagram section describes.

The book-of-record map, the same document the design decisions above produced, naming which system is authoritative for which field and how a disagreement between systems is resolved.

Change management evidence, showing that a change to an integration flow, a schema, a schedule, a retry policy, went through an approval before it reached production, not after.

Access controls, logging and monitoring for the integration layer itself, not only for the endpoints it connects, so that a question about who could have altered a flow has an answer.

The third-party oversight file, covered in the next section, because most of the estate in a banking integration is a service provider relationship, not a system the bank owns outright.

The rule most often cited in this space is not the one that binds a bank, and getting that backward is its own kind of finding. The FTC’s Safeguards Rule, 16 CFR part 314, defines who it covers in its own scope section: “You includes each ‘financial institution’ (but excludes any ‘other person’) over which the Commission has enforcement jurisdiction pursuant to section 505(a)(7) of the Gramm-Leach-Bliley Act.” That is an FTC enforcement jurisdiction, and it is scoped by exclusion, to entities the Commission, not a bank’s own primary regulator, has authority over.

A bank’s information security standards instead come from its own banking agency’s Interagency Guidelines. For a national bank or federal savings association, that is 12 CFR part 30, appendix B, whose scope section states plainly: “The Guidelines apply to customer information maintained by or on behalf of entities over which the OCC has authority,” naming national banks, federal savings associations, federal branches and agencies of foreign banks, and their subsidiaries. Other federal banking agencies carry their own parallel appendices for the institutions each supervises; which one applies to a given bank is a determination for that bank’s own compliance and legal functions, not a call this page makes for any reader. What this page states is the scoping fact, not the individual determination: a bank does not default to the FTC’s rule because it is the one most often quoted online, and it should confirm with its own compliance and legal functions, against its own primary federal regulator’s guidance, which instrument actually governs its information security program.

The oversight gap that produces a finding is rarely the bank’s own system; it is the vendor nobody assessed, because a core banking platform, a loan origination system and very often the integration platform itself arrive through a contract with somebody else. The Interagency Guidelines are explicit about what that requires: a national bank or federal savings association “shall: 1. Exercise appropriate due diligence in selecting its service providers; 2. Require its service providers by contract to implement appropriate measures designed to meet the objectives of these Guidelines; and 3. Where indicated by the … risk assessment, monitor its service providers to confirm that they have satisfied their obligations,” including a review of “audits, summaries of test results, or other equivalent evaluations of its service providers.” The FFIEC handbook’s third-party oversight section states the same expectation from the operations side: management should “review independent audit or other assurance reports demonstrating the third-party service provider’s ability to meet the entity’s AIO needs and provide services in a safe and sound manner.”

For an integration built by an outside firm rather than assessed after the fact, the vendor selection question is a different one than the pattern question above, covered at How to Choose a Custom App Development Firm for Financial Services. And independent review is itself a form of oversight a bank can commission directly: i3solutions has performed an independent verification and validation code review of a custom application built by a third-party vendor for a bank, confirming the bank’s objectives, milestones and success criteria and reviewing the vendor’s code for security and performance issues rather than building the application itself. The published case study, named here as “Enhancing Quality With an IV&V Code Review,” describes that engagement in full. It is a review and validation engagement, not an integration build, and it is offered here as one concrete example of what third-party oversight can look like in practice, not as a template every bank must follow.

Not every bank in this situation needs a governed integration platform, and saying so here is the same discipline this guide asks of every pattern choice above. A handful of stable nightly files that reconcile cleanly and that the business has never needed faster is not a problem an integration platform solves; it is a second thing to run and be examined on, for a risk that was already being managed. A core vendor whose contract forbids direct API access, or prices it out of reach, can leave scheduled batch as the only realistic option regardless of what this guide’s pattern section prefers. A bank in the middle of an acquisition, where the target’s estate will be absorbed or retired within a defined window, is often better served waiting until the combined estate is known before investing in a governed layer that may not match what remains. And a flow whose owner is a business function rather than IT, a spreadsheet a lending team maintains for its own workflow, for example, may not belong in an integration platform at all until IT and that business owner agree it should. None of these conditions is a reason to skip the documentation and oversight work above; they are reasons the transport, specifically, can stay as it is.

What this page has not claimed matters as much as what it has. The proof i3solutions can point to on this exact subject is a GLBA control-mapping review and a large-scale system that validates data arriving from thousands of external financial institutions, not a core banking system implementation, a payments processor engagement, a trading or order management system build, or a delivered SOC 2 audit or attestation for a bank. Those are not claims this page makes about i3solutions, in the same way they are not claims Workflow Automation Firms for Financial Services: How to Evaluate the Shortlist makes; the two pages say the same thing for the same reason. Nor does this page name any client; the proof below is anonymized because the underlying case studies are anonymized, and they are not being un-anonymized to make this page read better.

On the GLBA side, an i3solutions IV&V engagement validated requirements traceability from the underlying compliance framework controls through the delivered functionality for a vendor-built application, identified control mappings where the vendor’s interpretation of GLBA requirements diverged from the client’s expectation, surfaced test cases the vendor’s plan had not included, and produced the board-defensible attestation the audit committee required. That is the only GLBA-specific engagement in i3solutions’ proof register, and it is a review engagement against a vendor’s build, not an integration i3solutions delivered.

On the scale side, i3solutions implemented automated validation against mortgage-compliance rules for a national network of more than 7,700 financial institutions and 12 district banks, a system that manages over $40 billion in mortgages. The published case study, named here as “Empowering Mortgage Acquisition Through Digital Innovation,” describes it in full. That is data exchange with external parties at scale, under industry rules, which is the closest thing in i3solutions’ proof register to the subject of this page; it is not a core banking integration, and it named no Microsoft product in its own technologies section.

What i3solutions can commit to on a banking integration engagement is the method this guide describes: assess the estate as it actually runs rather than as it was designed, name the book of record before choosing a transport, put the flows behind a governed layer, and build the evidence set an examiner expects, delivered by senior, US-based Microsoft integration engineers from the practice described at Unifying Enterprise Operations Through Microsoft System Integration & Data Management. If your team needs a current data flow diagram, a book-of-record decision, or a design reviewed before the next exam, that conversation starts with a senior architect, not a sales process.