Since FINRA has given firms the green light to use the cloud, it’s important they understand how to make it 17a-4 compliant. Because compliance officers don’t want to be a Stooge if they go ahead and move their operations to Microsoft 365, then come audit time, it’ll be especially embarrassing when the regulator is in the office doing their regular electronic records request and the firm can’t download a sample data set from the cloud. (Which by the way is what FINRA does during the 17a-4 electronic records request: ask for a sample set of data from the firm’s archive going back from up to seven years.)

The big question then becomes: can a cloud platform like Microsoft 365, using its built-in compliance tools meet 17a-4? Is it enough without adding a FINRA designated third party (D3P)? In other words, can you configure Microsoft 365 itself (out-of-the-box) to prevent the deleting and modifying of emails on exchange, data on OneDrive, SharePoint, and Teams chats. Then also ensure its retain for 7 yrs. in its original format, and finally will Microsoft act as the FINRA D3P, supply the two attestation letters and perform the required functions as a D3P?

I tried to figure this out myself, and – with my technical background it should be easy, but quickly felt I was sent on a fool’s errand. I then began thinking, how in the world can a small FINRA firm, without an IT department make Office 365 compliant? And this is important, failing to retain data for compliance can cause big problems.

Now, according to a popular white paper by Cohasset Associates, a FINRA firm can simply use the built-in Microsoft 365 retention policies (when properly configured and carefully applied and managed) to meet FINRA rule 17a-4. Alright, let’s go with this and then we’ll say a small firm decides to move their office to the Microsoft 365 Cloud. Meaning, they’ll host their email with the Microsoft Exchange Online, store books and records on OneDrive for users’ personal storage, with SharePoint as their company shared storage, and of course Teams for video conferencing.

The first step then for making any system 17a-4 is ensuring no one can delete their emails. We won’t even talk about retaining electronic records because if a cloud platform can’t properly archive emails as per FINRA, its dead in the water right there. To prevent the deleting of emails stored on Microsoft 365 you need to apply an exchange on-line retention policy to users’ mailboxes, sounds simple enough, and surely Microsoft has a fancy web portal just for this.

So, I went ahead and tried to configure an exchange retention policy to retain emails in Microsoft 365 to meet 17a-4, and a red flag came up immediately. I noticed that a retention policy doesn’t really retain emails in a non-rewritable format: it just moves them to the archive items in Outlook, which the user can simply delete. I suppose if they do delete the archive item in their Outlook, these emails are available to search with the proper access to the eDiscovery tool, but I couldn’t actually recover any deleted emails through this tool. This is scary, because at this point the users don’t have their emails anymore, for example if you apply a retention policy, they are moved, and if deleted from Outlook they’re gone, this isn’t going to fly with FINRA. Not to mention the wrath compliance officers will face when users have all their old emails dumped to a completely different folder in Outlook.

OK, let’s continue with the theory that firms can use the exchange on-line retention policy so that emails are retained as per rule 17a-4, and that you are confident that if anyone deletes their email, you can access them using the eDiscovery tool built into Microsoft 365, and FINRA is happy with that. (Oh, and users have no problem with their emails being automatically moved around and deleted in Outlook without them knowing.) But wait! don’t forget that you need to do something else otherwise the admin can simply delete all the retention policies and email is no longer retained, oops!

You also need to configure and run PowerShell commands on the retention policies to apply preservation locks. Otherwise, any admin can simply delete them , and you’re back to square one. Now, I ask myself, do the experts who are promoting the Microsoft on-line retention policies for FINRA compliance think firms are going to run complex commands to set locks on all their email retention policies? Trust me, it’ll never happen and even if they figure it out, it’s hard to maintain and would leave the door open to many errors and misconfigurations.

Making email 17a-4 compliant on Microsoft 365 using their built-in tools is complicated: (1) apply an exchange on-line retention policy to everyone’s email box, (2) run PowerShell commands on the retention policies to apply preservation locks – small firms don’t have the expertise for this

Ok, but let’s say you manage to apply all the proper retention policies on your users Exchange mailboxes then you figure out how to successfully run the required PowerShell commands to apply the needed preservation locks, you’ll then need to get the two FINRA D3P attestation letters from Microsoft. This must be done to meet 17a-4 and a FINRA firm needs these letters from the provider that is archiving their data proving it’s retained properly. You’re going to need one letter – the 17a-4 Broker Dealer Letter and another letter called the 17a-4 3rd Party Storage Provider Letter. In addition to acting as the 17a-4 D3P, there’s also some very specific requirements the D3P needs to be aware of (for example, sometimes FINRA will request data directly from the D3P, to bypass the firm – good luck getting someone on the phone from Microsoft for this!) But we won’t even get into these details; if Microsoft won’t even give you the FINRA letters, your compliance plans are dead in the water here.

At this point I didn’t even try to call anyone at Microsoft to ask if they could provide the FINRA D3P letters, in fact I have no idea what number I should call, so I went ahead and googled “Microsoft FINRA 17a-4 D3P letters.” I was then directed to a site with a link to download a document explaining the capability of Microsoft 365 to support organizations in meeting their obligations under the New Zealand Public Records Act 2005. Huh? A New Zealand Records Act from 2005? Something was fishy about this.

I then did more google searches and found another expert claiming that firms can download a copy of the 17a-4 letters from The Microsoft Trust Centre Resources. (I guess a copy of the letter is a good start, however, the D3P letters must be customized for each customer- but I won’t get into that either.) Of course, this led me to another link to a Microsoft site, but the 17a-4 attestation letters were nowhere to be found, it didn’t get me anywhere, and it surely didn’t have other links to a FINRA 17a-4 attestation letter from Microsoft, at that point – I gave up!

I understand that Microsoft wants to have a finger in every pie; to be everything to everybody, but certain customers have unique data compliance demands, such as small FINRA firms, which cannot be met with a generic cloud solution. More importantly, firms don’t have the in-house expertise to “configure and carefully apply and manage” the built-in tools that Microsoft is selling as 17a-4 compliant. Finally, firms need specific compliance documentation and commitments from vendors to be fully compliant, which Microsoft is obviously not willing to provide or even openly address.