*   *   *

By Steve Cocheo, executive editor

*   *   *

As a non-techie, have you ever been tempted to ask your bank's IT director something like this:

• • Where can I view the Great Data Migration?

• • I M here-where are UAT?

• • Where can I see buildings that are examples of your local architecture?

Christinne Johnson and Stuart Lehr set out to teach compliance officers at ABA's 2011 Regulatory Compliance Conference how to not only avoid embarrassing themselves with gaffes like those above, but also how to get the action Compliance needs out of IT. Today, they pointed out, IT is essential to a compliance program's survival. So learning how best to work with IT staff, and learning some of the lingo, will help. (You can read an adaptation of a glossary compiled by Lehr and Johnson from the August ABA Banking Journal here. (Flash required))

"A lot of the problem is that you get lost with the first acronym," when talking to IT, said Lehr. He and Johnson presented a short glossary of tech terms for compliance officers (opposite page). Compliance officers should prepare a similar list of their terms for IT, they said.

Build a partnership with IT

Lehr and Johnson, by background, come from the two sides of the cooperation issue. Lehr, a veteran compliance officer with larger institutions and with PayPal, is now industry principal at the Finacle division of Infosys Technologies Ltd. Johnson is executive vice-president, applications development, at FirstBank Data Corp. FirstBank Data is part of FirstBank Holding Co., a $10.9 billion-assets banking company based in Lakewood, Colo. (She's also spent time in compliance.)

The pair stressed that communication will help improve things between Compliance and IT.

"Think of IT being a partner," said Johnson. She recommended that Compliance meet with IT to provide some perspective on how IT's efforts affect the bank's ability to comply, and how the bank's compliance affects the rest of the organization. Often, she said, IT is treated as a service provider, not as part of the bank's internal team, and doesn't see how projects fit into the whole, necessarily.

Frequently, Johnson continued, IT finds itself in "reactivity mode," with sudden demands dropped on it and no warning that they were coming. She urged compliance officers to give IT a rundown on what will be needed over the next year, to give IT management a sense of the resources that will be required to meet Compliance's needs.

Compliance may not know everything that it will need IT for, she said, "but you have some idea."

"IT lives and breathes ‘project life cycles'," said Johnson. The more Compliance identifies with that mindset, the more cooperation it will encounter.

"My own personal preference would be to know as early as possible," said Johnson. She suggested that Compliance write a formal forecast of needs that it will share with IT at its meeting, and update as circumstances and regulatory requirements evolve.

Upcoming issues-like new interchange rules-that will require changes to bank systems are "must knows," she added. Changes that will impact systems that involve outside vendors are especially important to know about as soon as possible. While internal systems can be more controllable, that doesn't mean changes will be simple, she pointed out. Regulatory requirements that affect a legacy system, for instance, may take extra time to update. In some cases the legacy system may even need to be replaced.

The speakers acknowledged that even with communication and understanding, both Compliance and IT face the realities of business. Frequently there isn't enough staff, time, and money to address everything that needs doing on the ideal schedule. IT faces many demands besides those from Compliance. And IT resources are always limited.

"Sometimes you have to settle for the piece you can get, if it's enough," said Lehr. "You have to compromise when you can." At times, the issue boils down to settling for what will simply achieve compliance, versus the ideal desired outcome.

Johnson also made this point: Let IT know how things turned out after implementation, after the project goes live and the public has been touched by it.

"IT people dedicate themselves to solving problems," said Johnson, "and they never hear anything about it." At least, they usually don't hear about it when things go right, she noted.

Don't drown IT in paper

Compliance officers read regulations for a living. They dwell in a world of paper and regulatory detail. They know that world, and understand what they are reading.

"IT doesn't think the same way you do," said Johnson.

Some compliance officers will be inclined to run out a copy of a regulation and turn it over to the IT person assigned to their project.

Don't do this, Johnson insisted.

"The IT developer never needs to see the regulation," Johnson said.

Foreign as that might be to a compliance mind, it goes back to IT's way of thinking, according to Johnson. IT only needs to know what the compliance function needs the bank's systems to do to be in compliance. So, she recommended, the way to get there is to write out a plain-English description of what is needed. That is what goes to IT.

Boil it down, break it down

"You can't expect the developer to understand banking and the compliance issues," said Lehr. "They are laser-focused technical thinkers."

With that in mind, he has developed templates for projects that answer the following seven questions:

1. Task. What is the regulatory requirement?

2. Translation. What is a "plain English" description of that requirement?

3. Result needed. What kind of specific functionality is necessary from the system to support this requirement?

4. Inventory. What functionality already exists to support the compliance need? If so, what enhancements may be needed?

5. Gaps. What functionality is lacking, that must be provided to fill the need?

6. Deadline. When is the functionality required?

7. Compliance validation. How will the new functionality be tested to confirm that it matches Compliance's requirements?

 "Often there is a communication divide between technical and non-technical individuals," said Johnson. "What often bridges the gap is the ‘why' of doing something. This helps them understand, and makes for a better solution."

To illustrate, Johnson spoke about the challenge of getting her organization ready for the Regulation E changes required for the "opt in/opt out" debit overdraft issue of 2010.

"We knew we had to do a lot," she said, "and we got the whole tech team engaged."

Again, different ways of thinking have an inevitable effect.

"Keep in mind that IT has different ideas of what might be changed, because they work differently with the system than you do," she said.

Finally, Johnson noted that sometimes bankers in client groups decide to cut IT out of the loop. They decide to "bring their own solution" to an issue.

But "circumventing IT is not a solution," she cautioned. She's seen people try it, and it doesn't work, in the end.

At some point, solutions have to "talk" to the rest of the bank's systems, and without IT, that won't happen.

This article originally appeared in the August 2011 ABA Banking Journal Compliance Clinic column.

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed