Category Archives: User Administration

01.21.13
by

It’s a matter of trust – or is it?

Yes, this is a follow-on to my “Who does what” post – because there was an element I wanted to treat separately.

A lot of the matches that an Operations or Compliance staff review are pretty straightforward. There are often name elements that just don’t match, so it’s easy to say that the listed entity doesn’t match the data.

Can you, at a minimum, trust lower-level staff to do that sort of triage? Getting rid of the bulk of potential matches by using someone other than the Chief Compliance Officer or Legal Counsel may be a good, simple, easily defensible trade-off of operational cost vs, regulatory risk.

Does that staff have to be Compliance/Legal staff, or could it be parceled out to the appropriate business unit? Money Transfer Operations staff might be more knowledgable about their payments, after all, and Human Resources is probably, from a legal standpoint, the better place to review employee screening results.

Beyond the patently obvious false positives, can you trust others with some of the day to day review work? Might Documentary Credit know about transaction-specific licenses that are relevant to their clients’ businesses, sparing Compliance/Legal from that spadework?

And let’s say you don’t inherently trust other departments or lower-level Compliance staff with certain final decisions. Could they do the research for you? That way, when it hit the Compliance Officer’s work basket, the bulk of the work would have been done, and only the decision-making would be left. And, in fact, had some data not been gathered, the item could be referred back so the other staff members could go out and retrieve it.

Mr. Watchlist is a fan of getting things done in the most cost-effective way, as long as it’s actually effective. If other, closer to the business and/or more inexpensive, staff can perform the same function as a highly paid Compliance or Legal officer, it would seem to make good economic sense to utilize them in that way.

An added bonus: involving less-knowledgable staff in the day to day review work builds their knowledge base and your firm’s compliance “bench” – some of those folks might want to work in Compliance or Legal one day, and involving them on an ongoing basis will enable them to have that career option, and make your firm’s Compliance capabilities more broadly based.

An added “D’oh” – this is not just a maxim for watchlist screening, or even just for Compliance activities. Spreading the wealth, especially across functional and/or business lines, adds to organizational strength – as Martha Stewart would say, “it’s a good thing.”

01.15.13
by

Who does what

Determining which staff members can perform which functions, and can access which pieces of data, and can do what with them, can be an art or a science – and that largely depends on the capabilities of the solutions you choose.

Of course, this is a very generic statement – this will be true for any multiuser application you choose to work with, not just watchlist screening. In that regard, when you delve into transaction monitoring, KYC or GRC solutions, the same concepts will still apply.

First, who can do what… how are privileges assignable in the application? Are there set roles you must use, or can you design your own? Are access to applications assignable on a one-by-one basis, or in blocks (e.g. all configuration functions, all batch file screening functions)?

Second, what data can be accessed… can the access to data be limited to specific business lines, functional uses or other subsets of your data, or does access to the function give you access to everything? For example, can someone be given access just to the HR employee screening results? Can someone be given access to work baskets dedicated to first-line triage, but not the folders where items are processed by compliance officers for final review?

Can some data be made publicly available, but others be on a need-to-know basis? And how are these assigned – by one’s role or other user-level setting (e.g. all supervisors from Accounting can see the higher-level Accounting work queues), by explicit assignment, or otherwise?

On a related note, if access to a function cannot be segmented, can you make changes that are applicable only to parts of the business? For example, can you make a false positive reduction rule applicable only to one department’s work? Or can you route matches by business line in addition to other factors? … or, do the limitations in the application prevent that level of detail?

Here’s an interesting example to think about: if you needed separate security administrators to maintain user records for different business units, but also needed high level compliance or audit personnel to be able to “see” all the work for all units, could you do it without having to resort to using internal procedures? Would restricting the access to the security personnel mean having to create separate processing silos for each business unit – which might force compliance or audit to have to have separate logins for each business unit?

Lastly, what can you do in a given function… can “read-only” access be granted? Can access to certain parts of function be limited by user-level settings? So, if User A access a work item in Folder B, can they potentially do things that User C could not do to the same item?

And you thought it was just a matter of giving out user ids and passwords… having these options creates an application environment that not only passes muster with your security staff, but gives you greater flexibility in how you run your operation. You can leverage the smarts in the system to enforce boundaries instead of having to manage them procedurally.