Bank Lawyer's Blog

Trickle Down Guidance

From the FDIC's Office of Inspector General comes an interesting little tale that may have slipped by your attention while you and the family were reveling in the latest bloviations from the walking, talking hairdo that is THE GREATEST SHOW ON EARTH, I PROMISE YOU!!!

The entire incident was triggered by a false alarm about a possible security breach of a third party service provider (TSP) that turned out to be some pesky adware. However, the FDIC IG, operating on the premise that no (non)crisis should ever go to waste, used its investigation of the incident to uncover sloppy security breach incident response policies and procedures by all concerned, including not only the bank and TSP, but by the FDIC's own Risk Management Supervision field office (RMS) as well.

The entire "Case Study" by the IG is less than two pages long, so I won't reiterate it in detail. However, I will use it to bleat about a couple of additional points of my own. The first concerns the application of the FFIEC Interagency Guidelines Establishing Information Security Standards to TSPs.

The Case Study observes:

The InteragencyGuidelines require FIs to develop and implement a risk-based response program to address incidents of unauthorized access to customer information. The Interagency Guidelines also provide that FIs’contractual arrangements shall require that TSPs implement appropriate measures to meet the Interagency Guidelines objectives.

I recently had a TSP respond to a financial institution's request that its agreement for technology services with the TSP (which services would give the TSP access to nonpublic personal information (NPI) of the bank's customers) contain a provision pursuant to which the TSP agreed to protect the security of the NPI with the brilliant argument that the TSP was not a financial institution and, therefore, was not required to comply with the Interagency Gudelines. I not-so-patiently relied that the Guidelines "recommended" that my client make them apply to the TSP via a contractual provision and, since my client took such "recommendation" seriously and incorporated such a requirement into its vendor management policy, if the TSP wanted to do business with the financial institution, its could either agree to the provision or not do business with the institution. The TSP's business people conceded the point and it added a provision to the agreement designed to meet this requirement.

This seems like a fairly common requirement, yet the TSP was a technology service provider that does a lot of work with banks. In the course of the discussion on this point, it was evident that if the vendor's representatives were telling the truth (I accepted their assertions at face value, since it did not alter my client's position whether or not they were truthful), we were the only bank to ever ask for this provision. If that is correct, then the regulators need to be a lot more diligent in their vendor management reviews, because there are a lot of agreements with this TSP that don't comply with the "recommendations" of the Interagency Guidelines. On the other hand, it was the TSP's lawyer putting forth this position, so maybe it was a bald-faced lie.

The IG's Case Study also noted that "[t]he Interagency Guidelines The federal banking agencies, including the FDIC, conduct periodic information technology (IT) examinations at FIs and their TSPs." Other regulatory guidance, such OCC Bulletin 2013-29, "recommends" that financial institutions place in their agreements with TSPs an acknowledgment by the TSP that such examinations are permitted and that the TSP will cooperate in the conduct of the same. I have always considered this a "belt-and-suspenders" approach, designed to ward off unnecessary delay, since the Bank Service Company Act gives the federal bank regulators this power to examine third party service providers. On the other hand, I have had a contract negotiator for one of the country's largest technology service providers tell me that their attorneys have taken the position that the law does not require the TSP to allow the bank's regulator to conduct such an examination. The TSP only permitted them out of the goodness of its heart, I suppose. Regardless, the agreement with the TSP should always have a provision that requires that the TSP to permit, and to provide reasonable cooperation in connection with, such examinations.

A final few nuggets I gleaned from the Case Study: (1) a contract with a TSP needs to require full cooperation with the financial institution in the event of security breach and other provisions that are designed to permit the financial institution to be able to meet its obligations the recommendations under another set of guidelines, the Interagency Guidance on Response Programs for Security Breaches; (2) as part of their initial and ongoing due diligence and monitoring of technology services providers, institutions would be well-advised not to neglect the TSP's security breach incident response programs, and make sure that the TSP complies with "cybersecurity best practices;"  and (3) just as the bank has a regulator looking over its shoulder and second-guessing it, so does the regulator. I'm not claiming that this is necessarily a bad thing, but you wonder how much of the effort in this area is directed toward placating Monday Morning Quarterbacks.

Rent-a-Charter vs. Strategic Alliance

In June 2004, I wrote a post about schemes by non-bank lenders, especially payday lenders, to "partner" with banks and thrifts in ways that would allow the non-banks to use the bank's or thrift's status to "preemept" "inconvenient state laws, such as those pesky usury limits. As I said at the time:

Apparently, the state-chartered banks involved in this practice are counting on the continued lack of objection by the FDIC, and the continued sympathy of state banking regulators who are eager to increase the number of state-chartered institutions that they regulate. In my opinion, this is a risky course.

I also pointed out at the time that national banks and federal savings banks could rest assured that their primary federal regulator would be scrutinizing their business arrangements with non-banks like Elizabeth Warren looking under her bed every night for a bad banker looking to steal all the cash she has hidden in the sock that she keeps under her pillow.

According to a recent client alert from Chapman and Cutler LLP, this bad old idea not only refuses to die, but has engendered state officials to take action to stop it in its tracks. While the alert discusses the State of Pennsylvania going after payday lenders who've aligned themselves with Native American tribes (which has been a problematic marriage for quite some time), it has wider implications for similar arrangements. In this instance, the Commonwealth of Pennsylvania alleged that the "true lender" for regulatory purposes was not a bank in Delaware that would have been exempt from Pennsylvania usury limits and licensing requirements but the non-bank website "originator" that did most of the origination work and derived most of the economic benefits from the loans. The authors note that in other jurisdictions, the court decisions have not been in lockstep on the issue of preemption, arrangements like the one challenged here are likely always to put the lenders in the regulatory crosshairs.

No clear rule has emerged although regulatory challenges almost certainly are more likely to be made when excessive interest rates and/or abusive sales or collection practices are involved. In this case, the loans imposed interest rates of 200% to 300%.

The alert notes that even though the court's decision involved only a motion to dismiss Pennsylvania's action, and that is a long way from a judgment on the merits, the red flags for financial institutions involved in such relationships are clear "because it demonstrates that plaintiffs will continue to raise the “true lender” theory and courts will not necessarily dismiss at an early stage (for failure to state a claim upon relief can be granted) “true lender” claims solely because a bank is the named lender on the loans, at least where there are allegations that the originating bank does not have substantive duties or an economic interest in the program."

In order to mitigate the risk of claims based on the “true lender” doctrine, companies that engage in internet-based lending programs through an arrangement with one or more banks should consider how the programs are structured. For example, consideration should be given to operations where the bank has substantive duties and/or an economic interest in the program or loans. We are aware that some internet-based lending programs are considering structural changes of this nature.

The firm also advises institutions to make certain that they comply with regulatory guidance governing relationships with service providers. They cite FIL-9-2016 and related FDIC guidance. I'd also suggest taking a look at the OCC's Bulletin 2013-29.

Or, for a change of pace, a bank considering one of these schemes might decide to take its entire capital to The Bellagio in Vegas, walk up to nearest roulette wheel, and lay it all on "00." I mean, if you like dancing along the razor's edge with insured deposits, you might as well go all-in. Plus, you get free booze as long as your money lasts. To hedge your bet, you might want to hold back enough to buy a one-way ticket to Havana (regular flights from the States start soon) just in case that method of income-generation doesn't work out as well as a strategic alliance with a non-bank payday lender.

Vendor Mismanagement

While banks have complained about the crushing burden of regulations in a post-Franken-Dodd world, in one area they could use a little more regulation. Not of the banks, but of third-party service providers to banks.

I have yapped repeatedly on this rag sheet about how banks need to treat regulatory guidance seriously. While some regulators send confusing signals about the legal enforceability of guidance, they have also made clear that they expect banks to comply with it. Period.

One piece of guidance that we have discussed is OCC Bulletin 2013-29 regarding third party relationships, which is a reworking and expansion of guidance first issued in in 2001 (OCC Bulletin 2001-47). Other federal financial institution regulators have issued similar guidance. One portion of that guidance deals with provisions that the OCC expects to be incorporated into written agreements between banks and their service providers. Banks who take regulatory guidance seriously attempt to ensure that their written agreements with their significant vendors meet the regulators' expectations.

If some technology service providers are to be believed, not many banks take the guidance seriously.

Repeatedly, attorneys who advise banks on such agreements will hear a common complaint: the bank asking for such a contractual provision is the only bank that has ever asked the vendor for the same. Putting aside my stock response ("You'll never be able to say that again, will you?"), let's take them at their word and see what this means.

Let's pick two provisions, access by the bank's regulators to the service provider's records concerning the services it provides to the bank, and a binding agreement by the vendor to provide the bank with a disaster recover plan and modifications to it. These aren't the only provisions. There are many more, but I don't make a living off this blog, so they'll have to do for now.

OCC Bulletin 2013-29 provides in part as follows:

In contracts with service providers, stipulate that the performance of activities by external parties for the bank is subject to OCC examination oversight, including access to all work papers, drafts, and other materials. The OCC treats as subject to 12 USC 1867(c) and 12 USC 1464(d)(7), situations in which a bank arranges, by contract or otherwise, for the performance of any applicable functions of its operations. Therefore, the OCC generally has the authority to examine and to regulate the functions or operations performed or provided by third parties to the same extent as if they were performed by the bank itself on its own premises.

That's pretty clear. Yet, we have repeatedly encountered service providers, including one of the major technology service providers in the United States, who have resisted such a contractual "stipulation". In one discussion, a service provider that was providing an online banking system and related customer-facing services asked the bank to cite the provision of the law that gave the OCC the right to have such access. When we gave it the citation to 12 USC 1867(c), it responded that its inside counsel did not agree with the OCC's interpretation of the Bank Service Company Act, and that examinations that it had permitted the OCC to make were purely voluntary and could be terminated at any time. We responded that we didn't give a flying fig in a rolling donut what its in-house counsel thought about the OCC's interpretation, since the law was clear on its face. In that case, we compromised on language that required such regulatory access "as is required by applicable law." However, we were told by that vendor that other banks did not insist on such a provision in the agreement.

With respect to business continuity plans, OCC Bulletin 2013-29 provides the following:

Ensure that the contract requires the third party to provide the bank with operating procedures to be carried out in the event business resumption and disaster recovery plans are implemented. Include specific time frames for business resumption and recovery that meet the bank’s requirements, and when appropriate, regulatory requirements. Stipulate whether and how often the bank and the third party will jointly practice business resumption and disaster recovery plans.

Recently, we have encountered a technology service provider who provides a critical online banking service that absolutely refuses to agree to any provision in the agreement that addresses business continuity plans or procedures. While it states that it has such a plan and that the bank can review it, it will not agree to put anything in the contract regarding such plans. Again, the bank was informed by the vendor that it has never agreed to provide such contractual protection to a financial institution, and that no other bank has insisted upon it. Again, this is a critical service provider whose service, if it went "offline" for any length of time, would cause intense heartburn to the bank.

These are only two examples. There are many, many more. It's as if not only are many vendors unaware of requirements that their bank clients must meet (and that have been required for over a decade), but that many banks do not care about complying with regulatory guidance. In the case of smaller institutions, there is also the problem that they lack the expertise to negotiate, or perhaps they believe that they do not have sufficient importance to the vendor to bargain effectively. Whatever the reasons, many of them are rolling over with their paws in the air instead of trotting in the other direction.

This leaves those banks that take regulatory guidance seriously in a tough position. Some of them are simply walking away and trying to find vendors who "get it," even if they are not the first choice from a purely business standpoint. Others end up negotiating with themselves to arrive at less-than-reasonable contractual compromises.

I have a couple of suggestions for the regulators. First, try enforcing the guidance across the board. There are financial institutions who are trying to "do it right," but who are being undercut by those who aren't. Moreover, use your authority under the Bank Service Company Act and otherwise to bring home to the vendors directly that if they want to play in this arena, they need to play by your rules. Some of them are not getting the message. Perhaps it would be helpful to start naming names on both ends of the spectrum. Perhaps that would get some attention.

In fairness, there are technology service providers who are doing it right. They understand the guidance, and while they are not willing to fall over and play dead, they are willing to make a reasonable attempt to accommodate what is essentially appropriate risk allocation between the parties, and appropriate accommodation to their customers' regulators' expectations. They "get it." Here's hoping that more of them eventually get the message, as well.

The Art of the Deal

Having empurpled with rage the kisser of a regulatory agency, I'd like to turn now to offending attorneys for various bank vendors who seem to take to personify the quality of some lawyers that business clients love to hate: we're "deal killers."

Actually, some of us are.

A case in point: a large financial institution sends out an RFP to solicit vendors to sell their services to the bank related toi a line of business that the bank is pursuing. There's a great deal of money to be made, so you would expect that the vendors who want to bid on the work would put on their best "smiley face" and also put their best foot forward. You would also think that they'd want to avoid offending the object of their affection by committing a faux pas akin to, while curtsying to the Queen of England, breaking wind with the force and sound of a watermelon hitting the sidewalk after a 10-story drop.

The initial contract that's customarily involved in a bank's RFP process is a mutual nondisclosure and confidentiality agreement, almost always drafted on the bank's standard form. Most vendors who are serious about bidding either merely review the agreement to ensure that they're not selling their children to an Eastern European white slave ring, then sign it, or request changes where there is a critical legitimate concern with a provision. Seldom will a bidder who seriously wishes to make a good first impression turn the nondisclosure agreement over to the equivalent of a first-year law student who's intent on spotting issues in order to make his contracts professor proud.

Then, you have the bidder who's counsel revised an entire paragraph on the first page of the nondisclosure agreement to change nothing of substance, only to re-designate clauses labeled "(i)", "(ii)," and "(iii)" to "(a)," "(b)," and "(c)." This is correct from a formatting standpoint, but in the grand scheme of things, so unimportant an issue to raise that it rings a bell as loud as Big Ben at the stoke of midnight.

The responsible bank officer ponders, "If this is how they act when they are romancing me, how will they behave like when they have had their way with me? How long will it take, and what will it cost me, to negotiate the vendor agreement if I select this navel gazer and picker of sub-atomic nits?"

Snatching defeat from the jaws of victory: it's a talent.

"[T]here are millions of people out there, just like you and me, with their thumb on the self-destruct button."--Etienne de L'Amour.

Is Vendor Risk Scoring Mandatory?

Notwithstanding the insistence of some inside and outside the federal regulatory agencies that regulatory "guidance" is not "mandatory," the cautious banker knows better. The headline in today's American Banker (paid subscription required) screamed, "Risk-Scoring Mandate Pushes Banks to Rethink Vendor Choices."

The word "mandate" may be thought a tad strong by some, and downright wrong by others. After all, the article referred primarily to OCC Bulletin 2013-29, which is officially merely guidance. However, as we've asserted repeatedly on this rag, a bank that doesn't treat guidance as mandatory is a bank with a strong streak of masochism.

The specific alleged "mandate" that reporter Penny Crossman is that banks "risk score" their vendors.

What regulators have been asking in their latest round of vendor management guidance is a far more detailed scrutiny of vendors: of their financial stability, debt, revenue, profitability, their cost structure, and product strategy, among other things.

In the past, a large, well-known vendor may have been a safe choice, but regulators are now saying it's no longer enough to choose a vendor because it's a market leader. They want to be presented with a scorecard that lets them review how banks evaluate their vendors in a consistent way.

"The regulators are forcing banks to sit down and say 'what if. if this vendor goes away, what are the risks to you?'" says Lawrence Kaplan, of counsel at the Washington, D.C., law firm Paul Hastings.

Along those lines, Bulletin 2013-29 also specifically provides that a long-standing relationship with a vendor does not negate the requirement that the bank do the "required" due diligence and evaluation on that vendor as it would on any comparable vendor, and make certain that it engages in ongoing monitoring of that vendor in an objective fashion.  Familiarity shall not breed comfort, is apparently the regulators' motto.

As Crossman points out, there's no one-size-fits-all risk scoring model. I've seen several, any one of which appeared to do the trick. However, it appears that some sort of numerical risk-scoring is becoming the rule rather than the exception for banks.

The regulators haven't even explicitly said banks must assign each vendor a numerical score, though they have implied it.

"Unfortunately a score for each vendor is an unstated expectation," says Paul Reymann, a partner at McGovern Smith Advisors in Washington.

[...]

"Examiners want to know how you went through that methodology," Reymann says. "How you measure that could be with numbers, 0 to 100, or red, yellow and green indicators."

Among the factors that could be included in such a model, the article mentions financial viability, ownership, scalability (ability to grow with the bank), concentration risk (vendor failure affecting a large number of banks), and compliance risk (can you say "online tribal payday lending? I knew that you could!"). Those are only a few. Consultant Walter Taylor has come up with a list of 30 of them. Obviously, the risk assessment becomes more important as the vendor becomes more "critical" to the bank, but the basic risk scoring ought to be done on all vendors to justify to examiners how you rated the vendor and why you made the decision to retain them (if you did).

A couple of quotes struck home, because they mirror my own experiences.

It's not that you can't use a startup, but the management of the bank will have to justify it to the board, which will have to justify to the regulators why they're using Larry's ATM Machines rather than Diebold," Kaplan says. "What benefit do we get out of that and why are we better off, other than price? It's going to be a critical issue."

[...]

"If you've got three people in a garage doing some type of real-time processing for you with deposits or credit cards, that's crazy," Taylor says."

It's not pretty when the bank officer's buddies, who, literally, are three guys in a garage (with a heck of a neat software code they've developed), have their spare balance sheet and income statement reviewed by the green eye-shades on the vendor oversight committee, who respond with a variation of "You're kidding us, right?"

With all the other stuff banks have to worry about, vendor management may seem like it ought to be small potatoes. It's not. If you treat it that way, you'll dodge the bullet for awhile, right up until the instant it carves a canoe in your skull. Vendor management is serious business these days. Take it seriously.

When Curry Speaks, All Banks Should Listen

The Comptroller of the Currency Thomas Curry gave a speech the other day (paid subscription required), and emphasized a couple of points that vendor management folks at financial institutions with various charters--state and federal, bank and credit union--and the lawyers who represent them,  would be wise to heed.

Comptroller of the Currency Thomas Curry said his agency is increasingly concerned about the cybersecurity risks from banks relying too much on certain vendors and using service providers in foreign countries.

Banks can end up becoming dependent on certain vendors because of consolidation in the service provider industry, Curry said in his prepared remarks for the Consumer Electronics Show's Government Summit in Washington. They can also be exposed to risks when they assign critical functions to outside vendors, including those that use foreign-based subcontractors.

"Banks need to consider the legal and regulatory implications of where their data is stored or transmitted, and make a determination as to whether geographic limitations are needed in their contracts," Curry said. "Finally — and perhaps most importantly — we are concerned about the access third parties have to large amounts of sensitive bank or customer data."

Here are a few take-aways:

First, cybersecurity due diligence of your vendor assumes critical importance when that vendor has access to customer data and other sensitive information of the institution. Access to sensitive information ought to make that vendor a "critical" vendor regardless of the dollar "value" of the contract. The institution needs to be able to document that it examined the information security procedures and systems and found that they met industry standards.

Second, the provisions of the agreement between the institution and such vendors on confidentiality and information security need to be "robust." This is especially critical when one or a couple of vendors of the institution have access to a lion's share of sensitive data. Read OCC Bulletin 2013-29, FFIEC's handbooks on the outsourcing of technology services, and other regulatory guidance. Make sure you know what contractual assurances you need and then make sure they're in the agreement.

Third, the financial institution needs to monitor the compliance of these vendors with information security safeguards throughout the life of the relationship. If a critical vendor's not providing an annual SASE 16 audit report of an appropriate type (SOC 1 vs. SOC 2), and not addressing problems raised by such annual reviews, you've got a problem.

"We expect the board and management to ensure that appropriate risk management practices are in place, that clear accountability for day-to-day management of these relationships is established, and that independent reviews of these relationships will be conducted periodically," Curry said in his remarks Wednesday.

That's a red flag, no?

Fourth, you need to read between the lines of what Curry's saying about "certain vendors." Pay attention to what's happening in the marketplace. If an article appears in the press that notes problems with a critical vendor, investigate and assure your self that any problems are being addressed. Review the web sites of the regulators for enforcement actions, and pay attention to what you find if a vendor is the subject. Pay attention to your own due diligence. If you gather necessary information but don't act upon it appropriately, your regulator will not be pleased.

Fifth, foreign subcontractors have become a "hot button" concern. I would recommend that in your vendor agreements with critical vendors you have adequate restrictions on the use of subcontractors. Among those restrictions ought to be that the use of a non-US based subcontractor requires your prior written consent. I represent banks that would never consent, but that's a story for another day.

If the vendor pushes back, that vendor ought to be a cause for grave concern. They're not doing you a favor by selling you their technology, although a few of the larger ones act that way, especially if you're a smaller institution. These concerns are regulatory concerns, matters of safety and soundness. If the vendor is large and representing a number of financial institutions, none of these issues should come as surprise to them. If you have concerns about a vendor, give your federal regulator a call and tell him or her about those concerns. As Curry makes clear, your regulator will be interested. Very interested.

ICBA Tries To Break The Choke Hold

The ICBA is starting to gag on Operation Choke Point. Before it and its members pass out from lack of oxygen, it's demanding that the Department of Justice loosen its grip on the windpipes of its members.

In a letter Tuesday to the DOJ, Independent Community Bankers of America president Camden Fine argues that the investigation known as Operation Choke Point has an overly broad scope and is hurting community banks' ability to compete with their larger peers.

[...]

[T]he ICBA letter suggests that the Justice Department is singling out smaller banks. "The indiscriminate targeting of community banks offering these services also places community banks at a competitive disadvantage with large banks," Fine writes.

The only lawsuit filed so far as part of Operation Choke Point was brought against a small bank in North Carolina, but large banks have also gotten subpoenas, according to sources.

As the linked article points out, huge banks have received investigative inquiries, but only a little bank has had an actual enforcement action taken against it. Bullies always start out with the smallest member of the group, hoping to intimidate those who might actually be able to fight back to be intimidated.

As the article also discusses, the complaints of the ICBA mirror those previously made by the ABA. Unlike the ABA, however, the ICBA's complaint includes the fact that community banks are being singled out for the harshest treatment. That distinction makes sense, inasmuch as the ICBA focuses on smaller banks, while the ABA leans more toward the interests of the bigger banks.

Both trade groups, however, make the very valid point that law enforcement authorities, and bank regulators, would do a lot less damage to banks and legitimate payment processors if, instead of beating up the banks they regulate, they went after the "bad guys" among the payment processors. If they did so, they might alleviate concerns of many that what the folks at the top are after is not a few bad apples, but entire industries engaged in perfectly legal businesses that "the enforcers" find "distasteful."

Banks Hire Hagglers

A few weeks ago, the American Bankers ran a story about how community banks were hiring outside consultants to negotiate major IT contracts with vendors.

Hiring consultants, including those who once worked at tech vendors, can make a difference, industry observers say. Vendors have an advantage because they are constantly negotiating deals, while bankers only visit the issue every few years, says Greg Schratwieser, president and CEO of International Consulting.

Paladin [an IT consulting firm] collects data tied to the processing contracts of financial institutions with less than $5 billion of assets. It then uses its database to determine whether a bank is overpaying for its services.

Not surprisingly, some IT service providers aren't happy to see the "hagglers" appear on the scene. My response would be "Tough." Then again, some IT service providers go with the flow.

Despite the head-to-head competition, consultants and core processors have a good relationship, says Stephen Ward, senior vice president of the global sales organization at Fiserv.

The presence of a third-party negotiator shows that a bank is serious about the contract, and it "instills a process that has a start time and end time," he says.

"If the bank is paying for that service, it is more likely to follow the timetable," Ward adds.

Spoken like a man who, when handed lemons, can whip up a gallon of tasty lemonade in no time flat.

Nowhere in the article is made the very important point that the consultant is only one member (albeit, a potentially valuable member) of the financial institution's negotiating team. Another critical player is the bank's IT counsel. The consultants who are described in the article are focused on the business terms, including pricing, add-on services, and term. Knowledgeable lawyers would be focused on other issues, such as legal risk allocation, including warranties, remedies, limitations, disclaimers, and indemnifications. As OCC Bulletin 2001-47 states, concerning risk assessment:

The risk assessment phase should include the identification of performance criteria, internal controls, reporting needs, and contractual requirements. Internal auditors, compliance officers, and legal counsel could help to analyze the risks associated with the third-party relationship and to establish the necessary control and reporting structures.

There is also contained in that bulletin and other guidance issued by the federal banking regulators, a laundry list of contract issues that should be considered and negotiated in third party service agreements. Again, input from legal and other areas of the bank is advisable to ensure that these issues are properly assessed and addressed in the written agreement between the bank and the service provider.

Hagglers may be a valuable add-on to the bank's other resources, but they're not the only necessary player on the evaluation and negotiation team of a financial institution's technology service agreement.

Vendor Management Is Still A Regulatory Hot Button

According to the FDIC, a common theme in IT examination downgrades is poor vendor management by banks.

Last year, in 46% of the FDIC IT examinations in which bank ratings were downgraded, inadequate vendor management was cited as a causal factor, says Donald Saxinger, senior examination specialist in FDIC's Technology Supervision Branch.

"I'm not saying it was the primal causal factor, but, in 46% of the downgrades, vendor management was cited," Saxinger says. He spoke during the recent ABA Telephone Briefing "Vendor management: Unlocking the value beyond regulatory compliance."

Although the most common “error” that FDIC examiners discovered was the failure by banks to ask their vendors for copies of regulatory examinations, that wasn’t the only nugget contained in the linked article from the ABA Banking Journal. Among the others:

• Vendor management needs to consider all service providers that hold sensitive customer information, not just IT vendors. These include loan workout consulting, appraisal review companies, outside attorneys, and others.

• Make sure to get the proper exam reports about individual vendors. Some banks just obtain reports for the host data center, but not for the specific application that the banks were using.

• Even the proper reports don't cover everything that a bank must consider in its security risk management efforts. For example, one service provider with an otherwise clean report did not have an internal audit program and its business continuity planning was poorly documented.

This is all sound advice, of course, but knowing what you need to ask for is only half the battle. You also need to make certain that the agreement with your vendor gives the bank the right to ask for, and the vendor the obligation to deliver to the bank, copies of the necessary reports. Relying on the goodwill of the vendor in coughing up examination and audit reports, especially when they may contain results that are less than flattering to the vendor, is "unwise."

Here's one more tip: if the report reveals problems, the agreement with the vendor should require the vendor to notify the bank of what action the vendor intends to take to remedy the defects, and should also require the vendor to give the bank periodic progress reports on its progress in correcting those problems.

I'll be doing a webinar on March 6, 2013 on the topic "Technology Service Agreements: Meeting Regulator’s Expectations." It covers regulatory guidance applicable to credit unions, banks, and thrifts, although the same essential principles apply to each. The goal is to discuss the provisions of a technology service agreement that regulators expect (and that sound business judgment requires) be included, and to give financial institutions guidance on how to approach the issues covered by each of those provisions so that the institution meets its regulator's expectations while also meeting the institution's business needs.

Cyberheists: Big Banks Increase Small Banks' Losses

Internet security guru Brian Krebs had an excellent post a few weeks ago about much of the attention on cyberheists may be focused on the security vulnerabilities of small banks and their business customers, the large banks are playing a large role in small banks' losses.

A $170,000 cyberheist last month against an Illinois nursing home provider starkly illustrates how large financial institutions are being leveraged to target security weaknesses at small to regional banks and credit unions.

I have written about more than 80 organizations that were victims of cyberheists, and a few recurring themes have emerged from nearly all of these breaches. First, a majority of the victim organizations banked at smaller institutions. Second, virtually all of the money mules — willing or unwitting individuals recruited to help launder the stolen funds — used accounts at the top five largest U.S. banks.

Krebs responds to a question often asked of him, whether it's safer for a business to bank with a large bank rather than a small bank, by asserting that it's a difficult question to answer "because banking online remains a legally and financially risky affair for any business, regardless of which bank it uses"

Businesses do not enjoy the same fraud protections as consumers; if a Trojan lets the bad guys siphon an organization’s online accounts, that victim organization is legally responsible for the loss. The financial institution may decide to reimburse the victim for some or all of the costs of the fraud, but that is entirely up to the bank.

That's right. Regulation E does not apply to business customers. That's something that sometimes comes as a shock to small business customers, especially those who were too cheap to hire legal counsel to review the account and other online banking agreements before they were signed. "Forewarned is forearmed" is an old adage with a lot of wisdom behind it. It's not that banks will negotiate the terms of their agreements (most of them will not, especially with small customers), but that customers who understand their legal position going into the relationship are more likely to be concerned about doing due diligence on the bank's security procedures and track record and considering other methods to lessen and cover their risks (I've seen a few who suddenly realize that having a PC dedicated solely to online banking transactions and no other activities is not such a waste of money, after all).

Krebs also points out that since larger banks are more likely to have the resources to settle even large losses to avoid the reputational risk of cyberheists, it may be difficult to know how many instances of loss occur. However, it's reasonable to assume that the large banks spend a lot more money and person-power on security measures than do small banks.

Wearing my cyberthief glasses, if I’m looking at a huge pile of data stolen from thousands of victims, I’m probably more apt to target victims at smaller banks based on one simple assumption: Because I’m going to have a much higher success rate than I would targeting customers of larger institutions.

Krebs takes a shot at technology service providers who service many of the smaller banks for not doing more to secure online banking transactions.

Case in point: Optimumbank’s service provider is Fiserv, one of the largest banking industry service providers. According to Fiserv’s site, at least 52 percent of the nation’s $19 billion in ACH payments are processed using Fiserv software. If this is true, one might think that Fiserv’s systems handled about half of the mule transfers that were sent from Niles Nursing’s hacked bank account.

But according to Murray Walton, Fiserv’s chief risk officer, the software that most of its customer banks run — called PEP+ – is a client solution that does not interact with the company’s data centers. He said while Fiserv does offer an antifraud solution called FraudNet, that tool is designed for online bill pay services that banks can use to detect fraud patterns on consumer accounts.

“There are vendors who can knit it all together for banks, but that isn’t what we do,” Walton said in an interview. “For various and sundry reasons we don’t offer an engine that does the same thing as [an anti-fraud provider like] Guardian Analytics. Realistically, the client and end-user have responsibilities that they can’t abdicate to us. Everyone in this needs to take it seriously and not think that someone else has their back.”

I understand Walton's point, but on the other hand, a small bank's takeaway from those three paragraphs might be "Fiserv doesn't have your back, so look elsewhere." A competing core platform and processing vendor that "does have your back" might have a tag line to use.

Large banks are also lambasted for allowing so many "mule accounts" to be established.

As it stands, the big banks don’t have an incentive to police new accounts for mule activity, because it’s generally not their customers who are getting robbed from this activity, said Avivah Litan, a fraud analyst with Gartner Inc.

“The bad guys shouldn’t be able to set up these mule accounts in the first place,” Litan said. “The bigger banks are not doing a good job of screening for this activity because they’re not the ones eating the fraud on these attacks on smaller bank customers. [The bank service providers] should be spending more money. And the regulators should be coming down on them harder.”

Krebs suggests that, perhaps, "small, regional and local banks can pool their clout and resources to extract more from service providers than what those companies are currently offering." Fat chance. Several years ago, some of the largest users of technology services in the country made a concerted effort to get giant service providers to take more contractual responsibility for the performance, and vulnerabilities, of their technology. It fell flat. Unless the bank regulatory agencies intervene directly with the service providers, they'll continue to do what they do best: collect fees and deny liability.

As for watching your own back as it applies to business customers, Krebs offers some good suggestions, among them:

• Shop around for banks until you find one that assures you that it uses layered security.
• Use "Positive Pay" if your bank offers it because it not only deters check fraud but other unauthorized transfers, online and off (I heartily concur).
• Use Live CD to temporarily covert your PC from Microsoft to Linux for doing online banking transactions.

Krebs also offers an online "best practices" guide for businesses. As with much of his material, it's good stuff.