Working in the compliance space presents us with all sorts of challenges when it comes to managing process and data. Whatever our ‘ideal’ workflow may be, or however our technology solutions are set up to handle compliance processes, regulation often forces us to make commitments that we are are not properly equipped to satisfy.
This is especially relevant when thinking about time-bound compliance requirements; that is, requirements on a firm to do something within a certain time frame. These might take the form of deadlines on producing some documentation, updating records in the event of any change, or carrying out a control action when a specified event happens.
When your compliance procedures were drawn up, these requirements were no doubt identified and suitable controls put into place to ensure that your timeliness obligations are being met. But could technology limitations be exposing you to unnecessary risks? Here are a few topics to consider.
1. Business as usual – can you produce the material on time?
The straightforward scenario when everything is working well is probably the one that was envisaged when your controls were drawn up, and so it should be the one where you’re most confident in your ability to deliver. But do you know exactly how long it takes to satisfy your obligations using your existing tools?
We spoke to a client who kept various client money records including third-party reconciliations on a remote network. Compiling this information was assumed to be a straightforward task, but when tested in order to produce a CASS Resolution Pack in less than 48 hours, this data was discovered to be very large – several gigabytes worth – and actually took longer than two days to transfer electronically over a system with poor bandwidth capabilities.
Equally, if you’re keeping compliance data in systems with poor version control (and if you rely on spreadsheets, then I’m afraid that this is you) can you be confident that accurate, up-to-date records can be produced quickly from these? Who changed this last? Didn’t Joe take a copy of this yesterday to work on? Where did he save it? With a compliance deadline looming, these are the last questions you want to be frantically trying to answer.
Test all technology infrastructure before it’s needed to ensure it performs adequately
Use centralised database systems to store important data, not spreadsheets
2. Disaster – how fast can you recover?
This is the nightmare scenario where everything is lost: your servers fail, data is accidentally deleted, or your office floods and nobody can get to their normal PC.
Having a robust DR (Disaster Recovery) plan in place is of course essential across all areas of the business, but when it comes to compliance the key question is: have you considered how long the process takes to initiate and resolve and then documented this against your obligations? It would be a rather unlucky situation to get a call from the FCA just as the flood water was pouring in the front door, but even in the normal course of business, unforeseen circumstances can and do occur.
Even a more minor event such as a file becoming corrupted could put you in breach if it takes longer than a few days to sort out getting a backup restored, and your choice of software may even be adding to this risk. Do you have enormous files with thousands of records that take a long time to open? Storing vital data like this is a problem waiting to happen.
Document all DR time limitations against your compliance obligations
Ensure that all important data is backed up and retrievable quickly
Consider off-site or secure cloud storage where possible to eliminate any disaster event concerns
Use data systems designed for volume where needed
3. Does tech introduce delays into your process?
The process or control looks simple on paper – but is it? If in practice it means several emails being exchanged, colleagues struggling to use a system properly, or tasks being neglected because they are too tiresome to complete to schedule, then you may be building failure into your compliance workflow.
Often this is an issue that creeps in with scale: a less-than-ideal tool was used for a process involving two or three people, but now twenty need to use the same tool and nobody has ever evaluated the effort being needlessly expended by the business as a whole.
Equally, using a tool for the wrong purpose can introduce the risk of error and making spotting or resolving it difficult. A formula which was accidentally broken six months ago because someone leaned on the keyboard wrongly could be causing errors to filter through every record since then without any chance of them ever being identified.
Count the cost that using the wrong software for the job brings to your compliance processes
Identify tools that people hate using; there is always a reason and a cost to this
Consider whether you’ll be alerted if people are behind on their responsibilities
4. How do you evidence compliance?
For any process with a regulatory time limit, you may be asked to evidence the fact that the limit is being obeyed. Does your software properly record the flow of updates that are made to your data? If not, then for all that your processes may, in fact, be fully compliant, you could end up struggling to provide documentation that proves it.
If you find yourself storing information in a ‘flat’ file structure – for example a text document or a spreadsheet – then you’re relying on the versioning features of the software package for your compliance obligations, and these are frequently limited in scope. Do you properly track all changes that people are making (and can you do this forever without the whole document becoming a mess) and is there a proper record of when a specific piece of information was changed, and by whom?
Bear in mind that the “last changed” date that your operating system shows for a file should not be relied upon for any sort of record-keeping, as this could be changed by people simply viewing the file or copying it, and will be useless in any situation where you need to restore the file from a backup.
Use software with deliberate audit features that record who changed information, and when
Where possible build in automatic triggers between systems – if something changes in application A, then application B should receive an alert that an update is required.
There are a few common trends in the topics above but the principal one is this: are you using the right software tool for the job? Not doing so could be building unnecessary time, inaccuracy, or risk into your compliance processes.
In a world where there are, increasingly, dedicated solutions available for what you’re trying to achieve (or bespoke software development at a cost that can often make great sense as a return on investment) you should always be looking to eliminate technology limitations from the list of things that add strain to the business – these limitations are often the cheapest and easiest to solve.