Financial Services
Microsoft 365, SharePoint, and Power Platform work for banks, asset managers, insurers, pension funds, and credit unions. Two pressures shape almost every engagement: a regulator (OSFI, IIROC, OSC, the provincial pension regulator) who will eventually ask to see the audit trail, and a Microsoft 365 tenant the company has paid for for years but which still isn’t doing the document-control or workflow work the regulator expects. The gap between the two is what we close.
Reference engagement — TD Wealth (Toronto, 2021–2023)
Two-year engagement consolidating TD Wealth’s SharePoint estate and shipping the document and reporting platforms that wealth-management operations actually run on.
Scope:
- SharePoint platform consolidation: migrated 1+ TB of SharePoint 2013 content into SharePoint Online via ShareGate, with phased cutovers and validation against an enterprise production environment.
- Wealth Report Center (WRC): designed and implemented a SharePoint Online report distribution hub for the Wealth platform. Built a custom .NET 6 C# service that monitors NAS folders, ingests reports, and uploads them into SharePoint with the right metadata applied automatically — replacing a manual file-drop pattern that had a long tail of audit and reconciliation issues.
- Data Quality Management (DQM) platform: architected a data-quality platform across Tableau, Azure Data Factory, Azure Databricks, Azure Data Lake, and Synapse. Built a Python + Handlebars templating tool to generate ETL configuration artifacts at scale rather than maintain hundreds of pipeline configs by hand.
- Integrations: C#/.NET against Microsoft Graph, REST, and CSOM for report distribution and content operations across the broader Wealth tenant.
- Production support: L3 ownership of team sites, custom lists, workflows, and security controls across the live environment.
The pattern from TD ports cleanly to other regulated financial-services clients: trust companies, asset managers, energy lenders, insurance carriers, and pension funds all share the same operational reality, and most are at the same stage of the SharePoint Online migration arc.
What regulated financial-services clients ask us for
SharePoint platform consolidation
The starting state is some version of: a SharePoint 2013 farm that needs to be off-prem before the next OSFI examination, multiple SharePoint Online tenants left over from acquisitions, a OneDrive sprawl that nobody has governance over, and a regulatory request that already came in writing. The work is rarely a pure tool-driven migration. It’s the inventory, the IA rebuild against actual records-management requirements, the permission-model reset, and the change management for the people who liked the old way. The TD engagement above is the reference; our Microsoft 365 migration guide covers the sequence we use at smaller scale.
Document control and audit trail that the regulator will accept
What an OSFI examiner actually asks for is reconstructable: every approval, every retention decision, every access change, traceable years later without a manual reporting exercise. We design SharePoint with that as a default rather than a quarterly project. Purview sensitivity labels and DLP scoped against actual records-management requirements (not the out-of-the-box Microsoft defaults), retention policies that match what your records-management policy says (not what’s easy to configure), and Power Automate workflows that produce the audit trail by default. The metadata model that holds up under audit is in our SharePoint DMS metadata post.
Custom code where the platform doesn’t reach
Power Platform handles roughly 80% of the regulated workflows we see. The remaining 20% is where C#/.NET, Microsoft Graph, REST, and CSOM earn their keep. The TD Wealth Report Center is the canonical example: a .NET 6 service that monitors NAS folders, ingests reports into SharePoint with the right metadata applied automatically, and replaces a manual file-drop pattern that had a long tail of audit issues. The decision framework for the make-or-configure call is in our custom software development post; the architecture pattern for the Power Platform side is in our Power Apps walkthrough.
How we engage
First contact to written response: one business day. We don’t run a discovery deck. We ask about the regulatory pressure you’re under and a timeline. The response back is a candid read on what’s actually possible, what controls are already in place to leverage, and what would be wasted effort. From signed scope to first usable build is typically four to eight weeks for a Power Platform workflow; SharePoint platform consolidations run on quarter-by-quarter wave plans against regulatory deadlines.
If you’re earlier than that — still scoping the problem, still mapping who owns what — a 45-minute call with a senior consultant is the right next step. No pitch deck. No junior account manager.
Related work
Reading on the patterns we ship for regulated financial-services clients:
- SharePoint DMS metadata that holds up under audit — the metadata model for records management against OSFI / IIROC / OSC requirements.
- Microsoft 365 migration guide — the sequence we use to move teams off legacy file shares and shared mailboxes without breaking anything in flight.
- Power BI dashboards over Dataverse — the pattern that produces audit-ready reporting by default rather than as a manual exercise.
- When to build custom software vs. configure Power Platform — decision framework for the make-or-configure call on internal regulated workflows.
Solution pages with the deeper context: payroll & accounting · field operations · asset management.
Regional pages with financial-services concentration: Toronto (Bay Street banks, asset managers, insurers) · Calgary (downtown energy lenders, trust companies) · Vancouver (real estate, brokerage, property management) · Edmonton (regional accounting + professional services).