Legal Technology Journal

Davenport Lyons’ IT director outlines the rationale and the methodology for creating a bespoke system for streamlining matter inception and client due diligence processes that ensures compliance and drives productivity.

Did you hear the one about the money laundering regulations change? Possibly not. The Law Society issued new guidelines on money laundering, client due diligence (CDD) as it is now known, in December 2007. The new guidelines focus on law practices taking a risk-based approach to money laundering. If you wade through this substantial tome you will eventually get a reasonable idea of how the Law Society would like you to approach CDD. The question is: why would you want to? After all, you are an IT expert, not a lawyer. Well, one possibility is that you are interested in client opening, client inception, or whatever the correct term is for getting a new client onto your books. With the ever expanding guidelines, the administrative burden for the solicitors has gone from a handshake over a pie and a pint, to the possibility of a complex detective exercise across continents, as well as the innumerable internal machinations that so often occur.

It is little wonder then that third-party software and services are springing up in this area. LTJ recently featured Nathan Hayes outlining Osborne Clarke’s BPM process for client inception using Metastorm. If you are an IT manager/director, and you have a pulse, you will have spoken to at least one vendor about their client and matter inception package. But are your options limited to those two avenues? I believe not, and, having developed a couple of useful applications in-house during the last couple of years, set about looking into the possibility of automating client and matter inception without recourse to third-party offerings.

As with any software development, a thorough analysis of the scenario you are trying to automate is key. Using third-party tools and consultants tends to make one a bit lazy in the approach to analysis, as a lot of the legwork is done elsewhere. Not so when developing your own code – detailed analysis is an absolute requirement.

As part of our requirements analysis, we tend to develop a broad-brush unified modelling language (UML) model and a detailed process map. The UML model presents a global overview of what we are trying to achieve. This is useful for explaining the general concept, which helps when trying to get buy-in for the project and explaining things to non-technical users. The detailed process map contains granular information about all the activities involved and will ultimately drive the software build.

The two UML diagrams that appear in this article are a representation of our findings about how we wanted to – as opposed to how we did – process new clients, and new matters. I included these as the process maps tend to be a bit on the busy side.

Matter inception

We had been keen to improve the opening of temporary matters – for example where money laundering/CDD checks were incomplete but work needed to start immediately – for some time because that was seen as a bottleneck in the business. This and normal matter inception seemed like an easy kill in terms of process build, so we set about that first.

Deciding what to develop your software in tends to lead you to two avenues – Microsoft, or whatever else. Whatever else looked good to us, although we did need to incorporate some of Bill Gates better efforts such as MS SQL.

We knew we had to query and write to our practice management system (PMS). We needed to query A/D for user account information, and we needed to write to our home-brew DMS. Once we had begun work on a prototype, we also realised that we would need to build an application specific database for auditing and rollback purposes. This was due in part to a need to track what is happening on a system like this, and partly because PMS systems, and the way they are used, do not always provide the right facility. Figure 1 shows how it looks in UML form. The next illustration shows the front end [Figure 2]. We deliberately kept this simple, used as much information from the PMS as possible, and made sure we kept things like order of drop-down list contents in the same sequence as users would see them in the PMS.

We made extensive use of drop down populated by PMS information. This makes the process reasonably simple. Once the user has posted the relevant information about their new matter an e-mail is generated and sent to the matter manager requesting them to authorise the transaction (on screen). As soon as the authorisation occurs, the originating requester, the matter manager and the fee-earner all receive details of their new matter, with a matter code. The system populates the PMS and the application database. It also populates the DMS and creates the corresponding document repositories.

We tested the prototype on a control group. In the testing process, a happy mishap occurred that told us we had got it right. One of the control group users processed a new matter, and selected a matter manager outside of the control group. We watched this on our monitoring software to see what would happen. The matter manager in question followed the process on the screen to its conclusion, despite having no prior knowledge of it. I quizzed him shortly after about what he had done and his verdict was that he loved it, as did the control group. That told us all we needed to know. We rolled it out a few days later, and got 100% take up of the facility instantly. That encouraged us to investigate client inception.

Client inception

For this element of the system we chose a similar style of presentation, and the same technological approach. Ideally, in order to get client inception working, you need to address the CDD aspect first, even though it is not the first element in the system. This is due to the nature of the CDD checks, which, irrespective of how you undertake them, will involve third parties. In order to promote consistent, reliable, auditable results, my view is that they should be carried out for the firm by a particular staff group rather than left to fee-earners or secretaries. There are a number of choices here, including having one or more persons dedicated to this task. However in a small-to-medium-size firm, where this may not be practical, there is a need to consider other possibilities.

Two types of employee that really lend themselves to this task are librarians and company secretaries. Both have good research skills, and have an understanding of company structures. The latter point is becoming increasing important as company structures become more complex, and multi-jurisdictional.

Those new regs in part...

The new CDD regs go further in their scope than previous efforts, partly to reflect the changing nature of the business landscape, partly to cope with more complex individual circumstances, and partly to ensure they fit in with directives from elsewhere. Whilst you may not be too interested in the scope of the regs, you need give them at least a cursory glance to understand how to develop software around them.

If you distil the new regs down to a palatable page or so, you should end up with something like this. Firstly, checks need to be carried out in four types of circumstance:

• when a business relationship is established;
• when carrying out an occasional transaction;
• when you suspect either money laundering, terrorist financing or similar; and
• when you doubt the veracity of information previously obtained for this purpose.

You could after reading the regs, add a fifth – when the nature of the clients business changes. You also need to consider whether you want to perform occasional ongoing checks for monitoring purposes.

We know from this that any new relationship requires checks. We can also deduce that keeping CDD information is important, and thus it needs to be part and parcel of any client inception system. To take this a little further, there are three elements of CDD:

• identifying the client, and verifying their identity;
• identifying any beneficial ownership; and
• obtaining information on the purpose and intended nature of the business.

The second and third points are largely self explanatory, but the first point needs to be handled in two distinct phases. Identifying a client is generally what the fee-earner does initially, but verifying them is a separate matter, and one which you are likely to get your compliance checker to undertake. The regs go on to explain in detail what is involved with the above, but for our purposes, that is enough for now. Armed with this, and in order to provide a complete and nicely packaged system, we can give the user a condensed set of rules, and thus a simple interface for conducting CDD within the system. This puts us in a position to ensure that the completeness and consistency required by the Law Society et al is adhered to whilst having the least amount of impact on the fee-earner. After all, the less admin they do, the more fees they earn, and the bigger your bonus will be, right?

Outsourcing CDD

The next question is how to undertake the checks themselves? One of the prominent elements of the Law Society guidelines discusses the possibility of outsourcing CDD checks. The regs say that it is OK to outsource, but your firm remains liable for failure to carry them out properly.

There are a number of agencies that now provide CDD information. These have grown in scope in recent years, partly one suspects in response to growing CDD requirements, and partly due to the increased availability of personal and company information.

Once you start delving into the services provided by these agencies you realise a few things:

• there are a number of them;
• they all provide different types and levels of service;
• no one supplier can cover every type of check required; and
• pricing models differ widely from supplier to supplier.

As a result, it is likely that you will need to use a combination of supplier offerings in order to carry out all the necessary checks, and also to ensure that you don’t lose sight of your budget. When we looked into supplier offerings, we found 90 different types of checks were available across the six suppliers we queried. Whilst they might not all be relevant in most circumstances, your compliance checkers need to be aware of who provides what. If anyone is interested, I can send you a copy of our findings to save you some leg work. We only incorporated six suppliers out of the eight or nine we encountered, so you might like to expand it further.

And back to client inception

Assuming you now have your in-house CDD handler in place, and that you have worked out which outsourcing suppliers you are going to use, you can now get on with the task in hand. By the way, you don’t have to outsource CDD checking, but my gut feeling is that you would struggle to do it quicker, cheaper or better by any other method. And in this age of transparent disbursement costs, it should be relatively straightforward to pass this onto the (eventual) client.

Our client inception system follows the form of the matter inception system in most aspects, including the software build. The UML diagram in Figure 3 shows a general overview of the system. By the time you read this we should have switched on the client inception element, work having begun in December 2007. As a result of being able to re-use large chunks of the matter inception module, development time should be reduced. The flip side is that extra time is required to get agreement on how the firm processes the CDD aspects. I have no doubt this will be the same in most organisations.

Figure 4 is a basic representation of the layers of the application. Working backwards, MSSQL was used for the application database, as it was also in use for our PMS, our DMS, and most other database apps, so it was a logical choice. From there though, Microsoft took a back seat. The ‘engine’, as we like to call it, is a JSP-based module that ties the front and back ends together. This was originally developed for our archiving system, but is flexible enough to be used for other purposes such as this. The engine provides data to the front end, writes and read to the connected data stores, and reads active directory information to allow user authentication.

The front end is web-based, and delivered through our intranet. It uses a combination of HTML, JavaScript and AJAX. The latter gives the developer the ability to display active content on the front end, for example delivering drop-down menus that are reading from PMS tables. All of this combines to give the user a simple but effective interface.

Hey presto

This rather glib description makes it look simpler than it actually is. The reality is that you need to have a skilled development team to develop the software, and you need to spend enough time and effort analysing and specifying requirements. Sounds like hard work, and sometimes it is, but what you should get in return is a piece of software that absolutely matches your needs, that won’t unexpectedly upset other apps in your enterprise and doesn’t come laden with extras that are simply not needed. Moreover, it should be far easier to manipulate, augment, change and add to, than a third-party solution. I’m not advocating that all applications should be developed in-house, but I do believe that if you have good developers, projects like this are achievable and deliver excellent results.

Damian Blackburn is the IT director at Davenport Lyons.