Don't get caught with your Transition Services Down (part 1 of 2)

By Mario F. Dottori

There is no shortage of commentary on why mergers and acquisitions fail or do not live up to their projected potential. The percentage of failed or underachieving deals is astounding with some placing the failure rate over eighty percent.The reasons for this dismal outlook range from ill-advised strategic vision, misaligned expectations and poor execution to cultural clashes, fumbled integration, and (some would say) misguided management objectives.

Over the past decade I've observed another factor that contributes to these suboptimal results: poorly planned, constructed and executed transition services, especially in connection with divestitures and carve-outs. The two main factors contributing to deficient transition service arrangements fall into two general categories: (1) a flawed perspective on the importance of transition services; and (2) errant development and execution of the transition service regime.
Let's explore each of these factors both in terms of how they arise and how they can be avoided, focusing first on what I refer to as the flawed perspective.

I can sum up the misconception about the importance of transition services in two statements:
  1. These are short term arrangements of less importance: Since transition services are only temporary (and hopefully very short in duration), they really are of less importance. Our focus is really on the long term success of the business.
  2. They pretty much relate to the back-office (and we need to focus on our customers and revenue drivers): Transition services mostly involve back-office operations, which don't drive valuations or contribute to the bottom line. We need to focus on revenue growth and our customers.

While at first glance these statements seem reasonable, they in fact underlie a host of conceptual shortfalls that drive behaviors which, at best, dilute the effectiveness of the post-closing enterprise and, in the worst case, result in unmitigated risks that can result in lost business, reduced revenues, or unanticipated liabilities.

With regard to the "short term" mindset, while these services generally are in place on for an interim period, they serve as a bridge to the broader (and longer term) integration of enterprise operations (both back office and front line). The thought that "we can fix things later" after the closing dust settles is a misstep that can lead to day-one business continuity issues (like interruptions in employee access to key systems), inefficiencies, (like additional license costs for unaccounted for but needed software), and employee dissatisfaction that can tug at the cultural fabric of the company. Not surprisingly, issues of this nature can (and often do) impact the customer and potentially the bottom line. This leads to my second point.

That is, what happens when the run of the mill business operations you've come to take for granted don't work (or are degraded or interrupted)? Setting aside the consternation of your own people, in some cases this can have a direct impact on your customers and hence your revenues. In the heat of deal negotiations, these subjects are often relegated to the back burner as they are viewed as lower priorities and are not "sexy" in the minds of the deal team. In an interview I conducted a few years ago at a M&A event with Argyle Executive Forum, the following exchange brought to light the hazards of this mindset:

In the context of overlooking the back-office (and the resulting inadvertent business interruptions), I posed a question along the following lines:

"...if all of a sudden we're having problems with the network and we can't email or data centers are having down time and someone in the field on the sales force can't get their tablet to record a sale, that's going to have a direct impact on business. Have you experienced that at all?"

The response was telling:

"We acquired a business in the U.S. and shame on us but we didn't put enough emphasis on the back office and it was certainly a learning process. On day one, the sales reps are going, 'Where are my reports?' And we ended up sending them paper copies until we got our act together. Shame on us, but I'm sure we're not alone. It was a detail that was overlooked, because it's not, as you said before, the 'sexy' part of the deal. But it gets real sexy when your customer says, 'You mean to tell me you didn't think about this?'"

The Right Perspective - The Value Imperative

Perhaps the best way to approach a transition services effort is to focus on what I'll call the value imperative for these services. From my perspective, the transitional aspects of a merger, acquisition, spin-off or divestiture must help achieve the following:

  • Ensuring a Competitive Edge & Risk Avoidance - In the new economy (characterized by rapid change, innovation being seen more like "table stakes" than a differentiator, technology-driven efficiency gains, increasing cyber/security risks and globalized competition), the transition services must position the post-closing enterprise to be even more competitive while at the same time appropriately protecting against business continuity risk;
  • Preserving Valuations - The transition services and related terms must at least preserve (and potentially enhance) valuations; and
  • Exploiting the Mission - The transition service regime must enable each impacted enterprise to better exploit the target synergies that drove the transaction in the first place.

Put another way, whether market-driven, opportunistic or as part of a broader strategy, what management (and the shareholders) really care about is exploiting the intended synergies to drive value. If there are transition services, they should be aligned with these objectives.

In the second installment on this topic, I will focus on the perils of poor planning, inadequate diligence and incomplete execution in transition service arrangements, and how these perils can be avoided through a disciplined and efficient process leveraging the right terms, tools and templates.

IT Services with Chinese Characteristics

By David C. Johnson

News of Alibaba's cloud investment and a recent software park tour indicate that China's IT services industry is evolving in its own way.

Alibaba Invades Silicon Valley
The "Amazon of China" is following Amazon's playbook yet again with their investment in the cloud. Aliyun, Alibaba's technology arm, already operates five Chinese data centers supporting 1.4 million customers. They cite high performance specs, such as the ability to process 80,000 orders per second during peak shopping season, and a successful defense against the largest recorded DDoS attack in China, which lasted 14 hours with a peak onslaught of 453.8 gigabytes per second.
Even with this performance, competing on Amazon's home turf will be no small task. Aliyun will initially pursue the growing number of US-bound Chinese companies. "We know well what Chinese clients need," explains Sicheng Yu, Aliyun's head of international; "now it's time for us to learn what U.S. clients need."

A Recent IT Industry Tour in Beijing
Nope, China is still not "the next India."
In spite of the hype that surfaces every few years, China is not becoming "the next India." India's unique path cannot be replicated. Yet, a recent tour of Beijing's Zhongguancun Software Park, where many new large buildings are bustling with bright-eyed, Starbucks-fuled youth, reveals that something is going on in China.
A few buildings housed familiar foreign brands (Oracle, IBM and Tata are there), though many belong to large Chinese IT service providers such as Neusoft, Pactera, and Beyondsoft.

If China is not the next India, what are all of these young workers doing?
  • Asian Roots; Global Ambition - The vast majority of China's IT outsourcing companies still serve Chinese, Japanese, and other East Asian customers - not insignificant markets. However, Chinese firms are expanding globally (1) by servicing Chinese branches of large multinational firms, and (2) by following existing Chinese customers abroad, as Aliyun is doing in the cloud space. The real value of these engagements is in providing a toehold for even deeper expansion.
  • Narrow Industry & Technology Focus - Chinese IT service providers tend to have deep technical strengths in narrow areas, often related to their legacy. For example, Aliyun was built to support Alibaba's online marketplace. As a result, Chinese firms may be most competitive when servicing discrete projects or components, rather than acting in a broader role as, for example, an IT Service Management (ITSM) provider.
  • Leveraging Hardware & Manufacturing Enterprise - China's manufacturing dominance has been successfully leveraged by some firms to create software and IT service offerings. For example, Neusoft, China's largest IT service provider, developed an expertise in telemedicine and medical imaging, in part through their role in producing both hardware and software for MRIs. They also opened a Detroit office in 2013 to focus on integrated automotive software.

While Chinese IT service providers cannot yet compete with the largest one-stop global IT shops, for an increasing range of geographies, industries, and service categories, they are providing unique value.

FTC Chairs warns of threats from the Internet of Things (IoT)

By Tim Wright

The Internet of Things (IoT), whereby miniature computers are embedded into objects and devices and connected via the internet using wireless technology, offers many advantages, such as smart thermostats which have the ability to remotely monitor and adjust your heating at home, and medical devices / apps which are used by patients to enable remote monitoring (e.g. a dangerous change in a patient's insulin levels).

Speaking recently at CES 2015, Las Vegas' annual hi-tech trade show, the chair of the US Federal Trade Commission, Edith Ramirez, warned of a future where smart interconnected devices enable technology firms to build a "deeply personal" and increasingly detailed and granular picture of consumers that will subject consumers to highly targeted advertising of products and services, as well as leaving them vulnerable to data attack.  Ms. Ramirez said that smart devices could potentially collect data such as an individual's health, religious and other lifestyle preferences, and asked "will this information be used to paint a picture of you that you won't see but that others will?"  Data should only be gathered for a specific purpose, said Ms. Ramirez..."I question the notion that we must put sensitive consumer data at risk on the off-chance a company might someday discover a valuable use for the information".

Regulators around the world are increasingly concerned to ensure that security and privacy issues are taken seriously by device manufacturers.  For example, the Article 29 Working Party[1] (the independent European advisory body on data protection and privacy) issued an Opinion in September last year which reviewed the IoT and the specific data protection and privacy challenges raised by it, assessed the state of the applicable law (in Europe) and made a number of recommendations applicable to relevant IoT stakeholders. These include a call for IoT device, O/S and application manufacturers, and developers to apply the principles of Privacy by Design and Privacy by Default and to undertake Privacy Impact Assessments (PIAs) before any new application is launched in the IoT.

We can expect the IoT to be increasingly subject to regulatory (and judicial) scrutiny over the next few years.  And for good reason. Last year, a study by HP found that the average IoT device has at least 25 security flaws, and there have been an increasingly number of disturbing real life events reported, including attempts to hack web-connected baby monitors as well as numerous hacks demonstrated by security experts and researchers, including internet routers, smart TVs, connected fridges and driverless cars.

ERP Licensing: Positioning Your Company For the Future (Part 2)

By Jeffrey D. Hutchings

This is the second of two postings that outline key pricing protections you should consider negotiating with licensors of ERP software to provide flexibility and predictability in managing the ongoing license and maintenance costs associated with the software.  In the earlier posting, we discussed future option discounts, exchange rights, and maintenance locks and caps.  In this posting, we focus on shelving and termination rights, acquisitions and divestitures, and successor products.

Shelving / Termination Rights

Shelving and termination rights provide the ability to reduce annual maintenance spend on unused licenses by either "putting them on the shelf" until needed or terminating unneeded licenses altogether.  There are three basic approaches to shelving and termination rights.  In descending order of desirability, they are:

  • Shelving - which allows you to shelve and later reinstate licenses subject to paying a reinstatement fee (typically based on the maintenance fees that would have been payable on the shelved licenses during the shelving period);
  • Termination - which allows you to terminate unneeded licenses to reduce maintenance fees, but does not allow reinstatement of the licenses (i.e., you would need to purchase replacement licenses if you later have a need for them); and
  • Termination Tied to New Buys - which allows you to terminate unneeded licenses only to offset maintenance fees on a contemporaneous new purchase of additional software from the licensor.

Licensors often strongly resist shelving rights and they can be difficult to obtain in the absence of considerable negotiating leverage.  As a result, termination rights may be the only viable option on some transactions. 

Some licensors take the position that termination is an all-or-nothing proposition; that is, the client must terminate every license to every licensed product in order to terminate even a single licensed unit of a product.  This is an outrageous position, particularly given the broad scope of products and functionality in ERP software.  At a minimum, you should push hard for the right to terminate either individual licenses or logical groupings of licenses without having to terminate all other licenses.

Acquisitions & Divestitures

Once implemented, you can expect to use ERP software for many years.  During this period, there is a good chance that you may acquire another company or sell off one of your business units. 

  • Acquisitions - To address future acquisitions, you should make sure that the license covers all existing and future affiliates of the legal entity that executes the license agreement.
  • Divestitures - To address divestitures, the license agreement should permit you to use the software to provide transition services to a divested business unit at no additional license or maintenance fees (other than fees associated with increased usage of the products). The transition period should extend for a minimum of 12 months and desirably longer.

Successor Products

From time to time, licensors will discontinue products and incorporate functionality from the discontinued products into new products.  This forces you to either migrate to the licensor's successor product or look for an alternative in the market.  Given the cost and criticality of ERP software, you should negotiate the right to obtain successor products without additional license or maintenance fees when they are released by the licensor (and in any event at such time as the licensor announces it will cease to provide mainstream maintenance on the product).  Licensors will often condition this right on you're not using any new functionality of the successor product.  However, the design of the successor product may make it impossible to avoid using new functionality and there should be an exception that permits your use of new functionality to the extent it cannot reasonably be avoided.

ERP Licensing: Positioning Your Company For the Future (Part 1)

By Jeffrey D. Hutchings

The licensing and implementation of ERP software is a major long-term investment for any company.  In addition to negotiating favorable upfront pricing for the software, it is important to build in pricing mechanisms that provide flexibility and predictability in managing the ongoing license and maintenance costs associated with the software.  This is the first of two postings that outline key pricing protections that you should consider negotiating with licensors of ERP software.

Future Option Discount

A future option discount provides a right to purchase additional software licenses at a specified price or at a specified discount off the licensor's then current list price.  This right has a number of benefits:

  • It provides predictability in licensing costs due to business growth and assures that the licensor cannot take advantage of you on future purchases when you may have little or no leverage in negotiating price.
  • It may enable you to reduce the initial buy, thereby lowering maintenance costs during the period in which the software is being implemented. However, you need to strike the right balance here. Reducing the size of the initial buy may impact the discount level the licensor is willing to offer. As a result, you should seek to achieve the optimal balance between (1) high discount levels on the initial buy, and (2) savings on maintenance fees by deferring purchases until licenses are needed.

In negotiating future options discounts, you should seek the following:

  • The option price should be the same or very close to the discount level as the initial buy.
  • The option period should be at least 3 years and desirably longer given the long-term nature of the investment in ERP software.
  • The option should apply both to the license of (1) additional units of previously licensed software and (2) existing and future software products of the licensor that are not part of the initial buy.

Exchange Rights

The initial buy of ERP software is usually based on a forecast of current and future demand for the relevant license metrics (e.g., named users, cores, annual revenue, etc.).  However, demand forecasts rarely prove to be 100% accurate.  Exchange rights provide the ability to swap licenses for which you have purchased too many units for licenses for which you have purchased too few units.

In negotiating exchange rights, you should seek the following:

  • The ability to exercise exchanges across as many licensed products as possible.
  • The ability to exercise exchange rights at least annually and desirably on a more frequent basis (e.g., quarterly).
  • A period of at least 3 years and desirably longer in which to exercise exchange rights.

Maintenance Locks & Caps

  • Maintenance - the "gift that keeps on giving" for licensors - is a significant cost in software licensing. For example, if maintenance fees are set at 22% of net license fees (which is the current standard among major licensors of ERP software), you are effectively paying the cost of a new license about every 4.5 years in the form of maintenance fees. The licensor should be willing to commit to a multi-year period - desirably at least 4-6 years - in which annual maintenance fees may not be increased and thereafter to some form of cap or limitation on subsequent annual increases, such as capped annual inflation adjustments.
In our next posting, we will focus on shelving and termination rights, acquisitions and divestitures, and successor products.

XL is Not Always the Right Fit: Sometimes the Right Contract Template is Not the Longest Contract Template

By Joshua Konvisser

As a thin guy, I used to subscribe to the philosophy of wearing large clothes to look bigger than I was.  What I actually looked like was a scrawny guy in ill-fitting clothes that were not overly comfortable.

Sourcing of IT and associated services may be falling into a similar trap.  Rather than using agreements that are the right shape or size, purchasing organizations are developing and rolling out standard templates that are supposedly broad enough to cover everything--unfortunately, they often do not cover any particularly purchase properly.  Specifically, we are seeing a proliferation of master service agreements (MSAs) that, largely speaking, come from an IT development context.  These are then begin applied to software licensing, professional services; and cloud services agreements--all of which are different transactions with different needs.

To illustrate, let's review the application of an MSA to a Software as a Service (SAAS) offering.  As a threshold, the MSA contemplates project style initiatives, whereas the SAAS offering is by its nature on ongoing, recurring offering over a specified term.  Under an MSA, the buyer typically attempts to assert ownership of all developments; this is antithetical to the SAAS model where the supplier contributes IP to continually improve its offering.  Under the MSA, the buyer heavily negotiates the service levels; in SAAS, the service levels are the same for all like buyers--without such consistency, there is no shared offering and no cost benefit of the SAAS model.  We could go on, but the point is clear--a customer MSA is not likely to be a good fit for a SAAS offering.

The MSA is not a bad document and it may well be suited for certain purchase.  In addition, there are many ways in which a template MSA may be used to the benefit of other types of purchases.  In fact, it may well be advised to review an MSA to identify gaps in another form of agreement, as long as one does so with an eye toward keeping out elements that do not really apply (I now have relatively broad shoulders, so shoulder pads are no longer a good fit).  That said, there are also strong benefits to using a properly tailored contract; not only will it streamline negotiation, it may actually much better fit the specific needs of the transaction at hand.

How to Fail in the Internet of Things

By Pillsbury Winthrop Shaw Pittman

Innovation is prized in the growing space of the Internet of Things.  But an innovative product design is not enough, and potential pitfalls abound.  As demonstrated in a report published by the Federal Trade Commission, privacy and security need to be at the forefront of developers' minds.  Here are five lessons on what not to do when developing a connected product.

The Internet of Things ("IoT") is an expanding ecosystem of everyday objects that are embedded with technology, allowing them to connect, communicate, and transfer information about users and their surroundings to each other.  IoT products boast beneficial effects such as increasing economic productivity and efficiency, encouraging robust innovation, and tailoring user experiences.  However, by virtue of being connected to the Internet, IoT products also carry privacy and security risks.  On January 27, 2015, the Federal Trade Commission ("FTC") published a report focusing on privacy and security concerns for IoT devices sold to consumers.

Given the growing interest in how embedded computing advancements affect security and privacy issues, this Alert identifies what developers, investors, and entrepreneurs should avoid when entering the IoT market. 

1.     1. Ignoring Washington, Sacramento, and the European Union.

Much has been written about how privacy and security laws are outdated and have not been able to keep pace with rapidly changing technology.  While legislatures may not have succeeded in updating statutes, regulators are laser-focused on privacy and security.  Ignoring the federal, state, and international efforts to deal with these issues would be a mistake.

Indeed, the FTC has made embedded computing a top focus.  In January, the FTC issued a report, Internet of Things:  Privacy & Security in a Connected World, that recommended steps businesses should take to enhance and protect consumers' privacy and security (FTC, INTERNET OF THINGS: PRIVACY & SECURITY IN A CONNECTED WORLD, January 27, 2015).  While the report is not formal legislation, it serves as a warning to IoT developers about the expectations of the FTC in this space.  The report offers recommendations regarding data security, data minimization, privacy notices, and consumer choice regarding collection of users' data.  The FTC also recommends that data security legislation be enacted by Congress. 

Even without IoT-specific legislation, developers should understand how technology-neutral laws are being enforced in the IoT context.  The FTC, for instance, has used its general consumer protection enforcement powers under the FTC Act, 15 U.S.C. § 45(a), regarding "unfair or deceptive acts or practices" to prosecute privacy and security violations.  Last year, in its first action against a marketer of IoT products, the FTC approved a final order settling charges that TRENDnet engaged in lax practices that failed to prevent unauthorized access to sensitive consumer information, namely video and audio feeds from its home security cameras (Press Release, FTC, FTC Approves Final Order Settling Charges Against TRENDNet, Inc., February 7, 2014).  Failure to comply with the FTC report's recommendations could result in FTC enforcement activity.  FTC Commissioner Brill has also encouraged state attorneys general to monitor the IoT industry and to bring actions for privacy and security breaches under general state laws that may apply (Julie Brill, FTC Commissioner, Remarks at Conference of Western Attorneys General, July 21, 2014).

While the IoT industry is in its early stages and IoT-specific legislation has not materialized, stakeholders in IoT devices should also keep abreast of developments in general data security and privacy legislation.  Certain states like California have taken active roles in the privacy sphere and have passed sweeping privacy legislation that can impact IoT devices.  Consumer class action plaintiffs and their attorneys are clearly paying attention to these developments, as evidenced by the onslaught of cases being filed.  Additionally, companies cannot forget that the federal government is increasingly requiring information technology devices and systems to have high levels of security before they will be bought by the government.  Federal procurement policy is rapidly changing to integrate security into contractual obligations, so companies that fail to have adequate security may see their government contract opportunities limited or even eliminated.

To the extent the IoT device is marketed internationally or if it is intended for travel, developers should also be familiar with privacy and data security regulation in other countries in which they are operating and where the IoT device is likely to be used.  The European Union, for instance, has very restrictive privacy laws and, under new amendments, Member State regulators have the ability to issue fines up to 5% of global revenues.

2.     2. Treating security as an afterthought.

It may be tempting to add security features to a device at the final stages of development so as not to hinder ingenuity or innovation in the early stages.  This approach, however, may allow for more security vulnerabilities to slip through the cracks than if security were considered at every stage of the design cycle.  Developers should consider security issues from the very beginning of product development--in other words, IoT "security by design."  IoT stakeholders would also benefit from acknowledging the risk of a data breach or use of the IoT device to conduct a cyber-attack inherent in a connected product and proactively developing an action plan in the event of a data breach or cyber-attack.

In the TRENDnet case mentioned above, the FTC alleged that faulty software for home security cameras left the live feed from the cameras open to online viewing by anyone with the camera's Internet address (FTC Press Release, supra note 2). When, according to the complaint, a hacker exploited this flaw and posted links to the live feeds to certain cameras (including babies asleep in their cribs and young children playing), it appears that the company did not have a way to repair the security flaw without forcing users to visit the website and download a software patch (Id).  

Stakeholders should think about these security issues from the start:

  • How can the company integrate security measures into the product as a way of enhancing the user experience?
  • Has the company completed a privacy or security risk assessment?
  • How will IoT devices be monitored for security vulnerabilities when they are out-of-date and new products are released?
  • Does the company have a system in place to receive information about security flaws?
  • How will software patches be released to users?
  • What is the procedure for handling a data breach and how will customers be notified?

      3. Overlooking internal security risks.

While a "security by design" approach to developing an IoT product is essential, it is not foolproof.  Developers need to think about security threats not just by hackers, but by their own employees and vendors. As the FTC report explains, companies must ensure that "personnel practices promote good security" and that "product security is addressed at the appropriate level of responsibility within the organization (FTC, INTERNET OF THINGS, supra notw 1, at 29)."  In addition, companies should consider the security practices of their contractors and vendors. 

Companies that handle data derived from IoT devices should consider the following issues about who has the data:

  • Who needs access to user data? Are there ways that access can be limited?
  • Are there clear policies in place regarding employees' handling of user data? Do those policies have buy-in from all of the important stakeholders?
  • Is the company providing reasonable oversight of employees' handling of user data?
  • Has the company considered the data security policies of contractors and vendors?

4.     4. Collecting as much data as possible, even when you don't need it.

Data collection is a powerful tool for analyzing behavior, developing innovative products, and providing valuable insights to users.  Collecting and retaining large amounts of consumer data, however, can present a more attractive target for data thieves.  When a large variety of data is collected, it also increases the risk that some of the data that is collected will be used in ways contrary to consumers' expectations.

While data minimization in the IoT context is challenging because a new use for data may be just around the corner, the FTC has encouraged companies to have data practices and policies that impose reasonable limits on consumer data collection and retention in light of that company's business needs.  One option to reduce privacy concerns is to immediately de-identify the collected data so at to minimize harm if there is a data breach.

Developers should consider:

  • Are the types of data being collected needed at this particular stage of design or implementation?
  • Is de-identifying the data an option? Is there a legal obligation to de-identify consumer data?
  • How long does the company need to keep the data to accomplish its objectives? When should the data be deleted?

5.     5. Believing that what users don't know won't hurt them.

The IoT presents many challenges to traditional consumer protection methods of notice and choice.  For certain data collection that is consistent with the consumer's expectations, providing choices for every instance of data collection may be overly burdensome to the consumer and not necessary to protect privacy.  However, where the data being collected is sensitive in nature or beyond what a user might expect to be collected, developers should consider methods to provide users with notice and choice regarding data collection.  The provision of notice to consumers about what data is being collected and with whom it is being shared is governed by a labyrinth of privacy regulations.

As to providing notice and choice to users, developers should consider:

  • Is data collection limited to data consistent with the context of the consumer-device interaction?
  • Are the company's privacy policies and terms and conditions of use customized, up to date, prominent and written in a way that is understandable to consumers? Has the company resisted the urge to cut and paste "boilerplate" policies used by others in the space?
  • When and how are notifications regarding collection of data provided?
  • In what situations will the company request users' express consent before their sensitive data is collected?
  • What options will users be given to control privacy settings?


If you want to avoid these pitfalls, start asking critical questions about the security and privacy implications of your IoT device from inception through implementation.

For more information, please read our Client Alert.

Potential Pitfalls in Data Licensing and Big Data Analytics

By Brooke L. Daniels

The trend in Big Data analytics among companies shows no sign in abating, with companies covetously collecting vast amounts of data with the hopes of harvesting market differentiators.  A study by open-source research firm Wikibon, for instance, forecasts an annual Big Data software growth rate of 45% through 2017.  But what tools are companies using to implement Big Data solutions? For purposes of this article, let's set aside for a moment the intended outcome of whatever Big Data project your company has planned in the coming year (whether it be predicting the outcome of Supreme Court cases or helping a baffled spouse pick out the right lingerie set), and instead let's focus on the tools available in the industry (and some of the associated pitfalls) in getting your company from concept to solution.

First, consider how you are going store and analyze the data.  For companies with significant internal resources and focus on Big Data, it may make sense to hire an in-house analytics team and invest in the requisite infrastructure and tools.  However, there are many options in the marketplace that require less investment in order to gain actionable insights:

§  Database Marketing Outsourcing: An end to end service often used by retailers in which a supplier licenses data and provides data mining analytics, marketing campaign sales management and analysis, and other ancillary functions.

§  Analytics-as-a-Service: A "software-as-a-service" offering through which a supplier can quickly deploy data analytics resources without an upfront investment from the customer.  AaaS offerings often draw data from external data sources as part of the services.

§  Data Warehouse: A central location to store copies of data from multiple sources.  Data warehouses vary in complexity from providing a relatively simple datamart to performing more complex functions such as online transaction processing. Generally, data is cleansed, organized and categorized in a manner to facilitate a customer performing its own analysis and reporting with the data.

§  Public/Private Cloud: A private cloud provides for easily scalable solutions that can be customized by the customer on a cost effective basis.  The public cloud is generally the most low cost option, but perceived risks in security and privacy prevent many companies from utilizing this option. 

As the lines blur in these services offerings, we are seeing more analytics and cloud services bundled into a single offering within the industry.

Once your company has determined a solution for implementing your Big Data project, what are a few pitfalls to watch out for?

§  Beware of the Supplier Form Contracts: It may seem obvious, but supplier contracts are almost always going to be very one-sided in favor of the supplier and negotiating is unlikely to give your company the same protections you will get when starting with your own form.  If possible, advocate for using an alternative, customer friendly form. If you don't have the leverage to use an alternate form, then just focus on the key terms (see below for a starting list of them).

§  Identify the Data "Pedigree": What data is going to be used in order to implement your solution? What is the source of data? Will external data be combined with your company's internally sourced data? Key questions for you to ask your supplier are : (1) where did the data come from, (2) how will the data be used as part of the solution, and (3) does the intended use of the data match the scope of the consent for which it was given? Ensure that the supplier has the right to use the data and that the use of the data matches the original scope of consent given by the individual that gave it.    

§  Define Your Rights to Supplier Data: If you anticipate using any supplier furnished data as part of your Big Data solution, then you need to ensure that you have clearly defined license rights to the data.  Typically, a supplier will license its data for specified terms that expire at the end of the agreement. However, if data licensed from the supplier is integrated into the customer's own data, then such data cannot readily be removed and may prove to be expensive to accomplish. In order to protect your company, try to secure unlimited perpetual licenses to any data that is integrated with your own data.  As an alternative, if you cannot obtain a perpetual license, then the supplier should bear the expense of removing the data from your data at the end of the relationship.  For example, if you are in the business of creating aggregated customer records or scorecards, where supplier data is merged with your data, then extracting the supplier's data will be an expensive and difficult thing to accomplish, and may be detrimental to your business.

§  Limited Supplier Termination Rights: Suppliers often ask for a right to terminate an agreement for convenience, or at minimum, for the right to not renew an agreement at the end of an initial fixed term.  Generally, it is acceptable for a customer to push back on these terms and argue that the supplier should only be able to terminate for material breach in limited circumstances.  However, it is not unrealistic that a supplier may have sound reasons for not wanting to renew an agreement (e.g., lack of predictability in the market, material changes in the service).  In any circumstances, you should ensure that you have sufficient notice and time to transition your data back from the supplier so that service is not impacted by the termination.  The contract should impose an obligation on the supplier to provide an actual plan on how the supplier will complete the transfer activities.

§  Protect Your Customer Relationships and Data:  Data analytics companies often rely on data you provide to improve their databases and enhance the services they offer all their customers.   They may also use the data you provide about your customers to establish their own contractual relationships and/or market other services directly to your customers.  While these arrangements may be acceptable in some contexts, make sure that they are clearly defined and that you have considered the implications of the data analytics provider's business model on your business and customer relationships both during and after the term of your contract.

§  Data Security:  If the data analytics provider will store or process your customer or other proprietary data in a cloud environment, the contract should impose clear data security obligations on the provider, including defining standards of care, SSAE 16 or other security audit requirements, and notification obligations following any unauthorized access or disclosure of your data.

§  Allocation of Risk:   Form contracts will often allocate most or all risks of using a data analytics solution onto the customer, even for claims that may arise through no fault of the customer.  Likewise, the limitations of liability in form contracts will often cap the provider's liability at a negligible amount while exposing your company to unlimited liability.  In most cases, it will be appropriate to negotiate a more balanced allocation of risk between the parties.

Keep these issues in mind whenever you are considering your next Big Data solution, and taking the first steps toward minimizing some of the inherent risks with data analytics.

EU Cybersecurity Regulations - The Costs of Financial Market Infrastructure Resiliency

By Meighan E. O'Reardon and Tim Wright

Any company that uses information technology is a potential target for data theft, advanced malware and other cyber threats.  Cyber threats have emerged as a growing systemic risk particularly to the financial sector in which Financial Market Infrastructures ("FMIs") are increasingly under attack from a wide range of players, at greater frequency and growing levels of sophistication.   Regulators, standards bodies and other authorities around the world are giving a high priority to cybersecurity for these reasons.  This post summarizes what regulators are doing in the Europe to address these threats and describes some of the actions companies everywhere can take to minimize their exposure.  


What are EU regulators proposing to improve FMI cybersecurity?

The European Commission has initiated a push to "protect open internet and online freedom and opportunity" by 2020. This initiative includes combatting cyber-attacks against information systems, establishing an EU cybercrime centre and coordinating Emergency Response teams, cyber-attack simulations and national alerts among all EU Member States. These efforts are also intended to align with the international fight against cybercrime. The next five years will see an increase in costs as FMIs and regulators pay to rapidly update single FMIs and solidify an EU-wide cybersecurity structure.

With a number of new regulations coming down the track in the EU, such as the General Data Protection Regulation ("GDPR") and the Network and Information Security Directive (commonly referred to as the "Cybersecurity Directive"), the implementation of the Principles for Financial Market Infrastructures ("PFMIs") into the regulatory frameworks of many jurisdictions worldwide, and the proliferation of standards such as the US's NIST Cybersecurity Framework, FMIs are faced with significant investment and operational costs as they pay increased attention to improving their cyber-threat prevention, monitoring, detection and recovery capabilities. Such regulations seek to impose 1) notification and reporting requirements on critical infrastructure providers and data controllers, specifically including financial institutions; and 2) near-immediate recovery times in the event of cybersecurity breach incidences. The minimum standards for cyber risk management in the EU are not expected to vary by type of FMI.

The Bank for International Settlements' Committee on Payments and Market Infrastructures ("CPMI"), a global standards setter charged with promoting the safety and efficiency of payment, clearing, settlement and related arrangements, thereby supporting financial stability and the wider economy, considers that the inability of FMIs, following an attack, to quickly resume operations in a stable state could cause systemic risk through transmission to the wider financial system. Hence Principle 17 of the PFMIs states that FMIs should implement business continuity plans that ensure critical IT systems "resume operations within two hours following disruptive events"; and are "designed to enable the FMI to complete settlement by the end of the day of the disruption, even in the case of extreme circumstances".  The overall objective of the PFMIs is to promote stability and efficiency in the financial system. CPMI concludes, however, that in the context of an extreme cyber event, a two-hour recovery objective would be extremely challenging for many FMIs.

As FMIs move towards faster recovery targets, they will likely experience three main areas of increased costs:

1.     An initial update of equipment, software and staff, along with periodic updates thereafter;

2.     Drafting of internal policies, procedures and training programs that are regularly updated and tested for efficiency and vulnerabilities; and

3.     Improved capabilities to detect cyber threats, which will correspondingly increase the need to record, respond to and report those incidents, in some cases to multiple regulatory bodies.

Regulators have also increased the incentive for FMIs to invest the above costs in improving cybersecurity by threatening hefty fines for financial institutions found to be non-compliant. Under the EU's Cybersecurity Directive, businesses will be fined a percentage of their revenue, though such penalty may be eliminated absent intent or gross negligence. The level of regulatory scrutiny an organization receives may depend on its role in and impact on market-wide cybersecurity, meaning the bulk of security audits will probably target high-risk industries and businesses like FMIs. Likewise, under the GDPR, the European Parliament proposes that sanctions be up to 5% of annual worldwide turnover or €1,000,000, whichever is greater. In preparation for and response to these regulations, FMIs must balance the costs of upgrading and maintaining their cybersecurity with the risk and cost of sanctions.

What should FMIs do next to meet cybersecurity challenges?

Putting in place appropriate contractual and governance safeguards is paramount. FMIs need to ensure that data loss and corruption caused by the service provider will amount to a breach of contract, though if the service provider is able to restore data from back-ups and does so within the time period stipulated in the contract, the service provider arguably should not suffer further liability to the FMI. A truly comprehensive program requires managing cybersecurity in an integrated fashion using a combination of in-house and third party resources. 

The complexity of IT environments and the increasing sophistication of bad actors make this a difficult situation to manage and control without outside assistance.  All facets of IT are at risk, from applications to centralized infrastructure, to even the most mundane endpoints.  FMIs and their outsourcing partners would do well to focus primarily on isolating network components and important information, as well as managing personnel interfaces with network and data access points. Several isolation strategies are key to cyber resiliency:

  • ·          Ramp up in FMI compliance with new regulations will drive opportunity for the IT services sector, with the adoption of new technologies and practices such as VMs and VDIs (virtual machines and virtual desktop images), which can be reset to a known "golden state" to, in effect, remove malicious software installed by a cyber-attacker, and heuristic monitoring that is used to detect anomalies such as abnormal usage of an application or abnormal transaction behaviour.

  • ·          FMIs may set up processes to capture transaction and other important data in near real time and store that information outside the main or central system. Frequent reconciliation against the stored records could assist with ongoing detection of corrupted or fraudulent transactions and cyber-intrusions, or during recovery to return the system to the "golden state". 

  • ·          To avoid significant data losses, FMIs should ensure that back-ups are made at regular intervals by the service provider and that the back-ups are also regularly tested to confirm that it is possible to reload the data. If a loss of data occurs, the stored information can then be reloaded from the latest available back-up.

  • ·          The access points of any FMI network should be limited by reducing the number of internet gateways and whitelisting software.

  • ·          Incorporate "defence in depth" strategy, which layers systems and system components and builds firewalls within the network. If one component is then compromised, an attacker could not access another component without breaching another obstacle. Internet-facing applications, such as e-mail software, are considered to be of greatest risk and should therefore be a top priority for isolation from core system components.

  • ·          Install proactive measures like hacking back, cyphertext, which requires users to enter a key code prior to opening information, or cryptographic defences that encrypt sensitive data, from HTTPS protocols to VPN clients.

  • ·          Keep confidential or critical information in separate storage systems, ideally at a separate data centre. Different systems covering different functionalities within an FMI, for example wholesale and retail payment systems, may be set up as each other's backup system in the event of a security breach.

An integrated approach to cyber resiliency covers not just an FMI's IT infrastructure, but also personnel, procedure and communications. Often the most severe data security breaches "result from inadvertent or deliberate acts of employees or contractors". Disgruntled employees are a high risk area as data can easily be sent into the cloud and physical copies do not need to be removed to create a data leak. Strategies to limit personnel-rooted cybersecurity vulnerabilities include:

  • ·          FMIs should require service providers of IT and other outsourced services to warrant that only personnel who are properly vetted, by the Disclosure and Barring Service in the UK or a similar body elsewhere, have access to the service infrastructure. 

  • ·          An FMI's entire staff - operational, senior management, board level and service provider personnel - should be involved in the drafting and implementation of security and recovery plans and procedures. 

  • ·          Organization-wide password management, locking of computers when not in use and physical security of data storage centres should be considered as a governance issue.

  • FMIs may also want the contractual right to interview key provider personnel and/or to require that personnel it objects to are removed from the service provision arrangements. Service providers are likely to resist inclusion of such provisions, so balancing risk versus cost should be the key metric in drafting an agreement.

  • ·          In this era of Bring Your Own Device ("BYOD"), employees expect to access FMI systems from their own computers, tablets and phones. Security of these devices is often in question, particularly if multiple users have access to the device, so two-factor identity verification prior to access should be standard. 

  • Encryption before transmission of information between the FMI's premises and the service provider's premises or between both such locations and any other remote access location may also be desirable.

·   The Big Picture

FMI efforts to integrate and manage compliance with cybersecurity regulations in outsourcing arrangements should start early and continue throughout the contracting lifecycle. Due diligence, negotiation of terms and conditions, including governance structure, liability and audit and risk assessment provisions, should all be considered part of the agreement's overall security strategy. FMIs should recognise that some data loss and corruption is likely to occur, but the ability to respond quickly to incidents and make the appropriate risk management decisions will be defining characteristics of a strong FMI cybersecurity program.

Global App Enforcement Sweep - Lessons For Developers

By Steven P. Farmer

A recent survey of over 1,200 of the top mobile apps in 19 countries by the Global Privacy Enforcement Network ("GPEN") has found that 85% of the apps reviewed were non-compliant, failing to provide even the most basic privacy information to users. 

In addition, 43% failed in their obligation to tailor privacy notices to smaller screens and almost 30% unlawfully requested excessive personal data from users.

Concerns for users are compounded given the lightning speed at which new apps are hitting the market.  Last year, for example, in excess of 1 million apps were reported to be available via Apple's iOS App Store.

Should developers care about these findings?

In short, yes, especially given that the UK privacy regulator, the Information Commissioner's Office ("ICO"), has recently conducted research that demonstrates that around half of app users have decided against downloading an app due to privacy concerns at some point in time. 

Risk for developers does not stop there either. 

As has been well reported elsewhere, privacy regulators in Europe now have the power to fine developers "on the spot" who breach relevant laws.  For example, in the UK, the ICO has the power to issue fines up to £500K (approximately US$800K).

Some regulators, including the ICO, have further announced that "mobile" has now been moved to the top of the enforcement agenda.  In other words, the regulators do have a stick and they appear willing to use it.

When brand damage associated with any enforcement action (such actions are published) and potential civil action is thrown into the mix, this could well compound problems, or even sound the death knell, for any developer who chooses to ignore privacy compliance.

I'm an app developer - what should I do?

The ICO has published guidance for app developers to help them understand their legal obligations when collecting personal data and to ensure users' privacy.  By adhering to this guidance, developers will be much less likely to fall foul of EU/UK privacy laws and find themselves on the end of an enforcement action.

The guidance covers key issues such as how to communicate privacy related information to users, how to obtain meaningful consent from users (all in the context of a small screen), as well as how developers should keep information within an app secure.

Top tips for privacy compliance during app development include: (i) using "in-time" notifications when more intrusive data is being collected, e.g., GPS location data; (ii) using links to separate sections of a privacy policy and to keep things short and snappy (given the size of screens involved); and (iii) avoiding being legalistic in language used in privacy notices.


This app sweep by GPEN is one of the latest initiatives which suggests regulators are taking compliance issues in this area much more seriously and that a greater use of enforcement action is on the horizon.  The time is ripe, therefore, for developers to audit their data collection and data use activities and to review the policies they have in place to assess their exposure to regulatory enforcement.  Transparency and clarity are key.  Adhering to such principles should not only help keep the regulators at bay, but also have a significant effect on a developer's bottom line.

You've been fired!

By Lisa C. Earl

It isn't often that a supplier "fires" its customer, but it's not unknown. I have worked with two clients recently whose suppliers have given notice of termination without cause.

How can you avoid or, if it does happen, manage through a supplier-initiated termination?

Obviously, the best position from a customer's perspective is not to give your supplier a contractual right to terminate, except if there is an uncured material breach. However, in many negotiations in which I have been involved over recent years, suppliers are demanding a right to terminate for convenience, or a right to give notice of non-renewal at the end of an initial term, or a subsequent renewal term (which pretty much amounts to a termination for convenience).

There are any number of reasons why a supplier may require a termination right. It might be a new area of business, and they may not be able to project the business case for supporting the business beyond a limited period. It may be a line of business that is already costly to maintain, and they don't want to be locked into a business that may become unprofitable. They may already have a number of "troubled" client contracts, and be seeking an exit right for all new contracts in order to avoid being locked into a bad deal.

If you are forced to give your supplier a right to terminate for convenience (or reject a renewal), then it's important to consider what you will need to do in that circumstance. How long would it take you to move the services to an alternative provider, or to ramp up the necessary resources to bring it in-house? What information, software, tools, equipment and assistance will you need from the supplier in order to make a successful transition?

Few companies are nimble at executing the sourcing process - that is, identifying potential vendors, seeking proposals, selecting the appropriate supplier and negotiating the terms of a new agreement with them. Even under the best circumstances, the cycle can take many months to complete. Adding in the contingencies of other business demands, availability of resources, and the availability and willingness of suppliers to devote substantial time to the process, you could be looking at a year or more to be in a position to transition from an existing supplier to a replacement. If you planned and initiated the termination, you would probably start working towards that well in advance, with consideration of other projects that are being implemented within the company, seasonal peaks and troughs and other business demands. In contrast, the notice of termination from a supplier may come without warning, and will not necessarily be able to be managed to accommodate your business cycles.

The best protection you can have in a termination by the supplier is a long lead time. It's not unreasonable to ask that the supplier provide a year's (or even more) prior written notice. That will give you a reasonable amount of time to work through the sourcing process to find and contract with a replacement supplier, or to ramp up the resources and expertise to bring the services back in-house.

You should also ensure that your contract contains detailed disengagement provisions that specify the supplier's obligation to provide you with data, cooperate with you and a replacement provider, and implement a well-planned and well-executed transition. The contract should also be very clear about your rights to resources on termination. Are you entitled to software (and, if so, to source code), transfer of hardware, assignment of third party subcontracts, including leases and licenses, and can you (or your new supplier) hire key supplier employee that will ease the transition?

A solid contract should deal with all of these issues regardless of who initiates the termination, but may be more significant when termination is forced on you by the supplier.

The "Subjective" SLA - Key Stakeholder Satisfaction

By Jeffrey D. Hutchings

Quantitative measures of supplier performance in the form of service levels are critical in any outsourcing relationship.   However, they provide an incomplete picture of how well the supplier is performing and meeting the client's business and IT objectives.  A common complaint is that the service levels are green each month, but the client is dissatisfied with the supplier's performance - typically due to the supplier failing in areas that are difficult to measure quantitatively. 

To fill this gap, we recommend to our clients that a quarterly "key stakeholder satisfaction survey" be included in the outsourcing contract as a service level.  This service level is a subjective determination by the client of its level of satisfaction with the supplier's performance.  A meaningful service level credit applies if the supplier fails to achieve an acceptable rating. 

Here's how it works.  A small group of key client stakeholders - typically senior representatives within IT and the business who are impacted by the outsourcing - meet on a quarterly basis to review and rate the supplier's performance during the previous quarter.  Together, they complete a "survey" that evaluates the supplier in key areas, such as account management, operational management, financial management, knowledge management, business enablement and innovation, value of services and overall customer experience.  The completed survey will include specific comments, observations, concerns and recommendations for improvement, together with the key stakeholders' overall rating of the supplier for the quarter.  The results of the survey are then shared with the supplier's account management team and discussed as part of a quarterly performance review meeting.

The overall rating is on a scale of 1 - 5 based on the key stakeholders' collective determination of how well the supplier is meeting expectations and perceived to be adding value and contributing to client success.  A service level credit may be assessed if the supplier is failing to meet expectations on a consistent basis.  The amount of the credit is scaled based on the degree to which the supplier is failing to do so.  Like other service levels, credits are typically based on a percentage of the supplier's fees for the measurement period.

As might be expected, many suppliers initially resist a credit-bearing subjective measure of their performance.  However, our experience has been that most suppliers will ultimately accept this service level.  A key element in gaining supplier acceptance of this service level is allaying fears that the client will use this service level as simply a means to trim some money off the supplier's charges each quarter.  This often comes through a realization that the client needs to provide honest appraisals of the supplier's performance in order for this service level to be an effective tool for the client to drive improved performance and that performance improvements are far more valuable to the client's business than the amount of any financial credit the client could collect under this service level.

Experience has shown us that a key stakeholder satisfaction service level is a powerful tool for clients to focus the supplier's attention on the areas that matter most to the client and fill the gaps in what can be captured through traditional "objective" service level measures.  As a result, we think this SLA should be on every client's "top 10" list of most important outsourcing provisions and is well worth the time and effort spent on negotiations with suppliers to make it part of the contract.

FCA issues considerations on the procurement of off the shelf technology solutions (United Kingdom)

By Simon J. Lightman and Mike Pierides

In July, the Financial Conduct Authority (FCA - the financial regulatory body in the United Kingdom) issued a paper titled "Considerations for firms thinking of using third-party technology (off-the-shelf) banking solutions" (the Considerations).  The Considerations contain about five pages of checklist "Areas of interest" and related notes, which are stated to be things a firm subject to regulation by the FCA should consider when procuring 'off the shelf' technology solutions.    

When do the Considerations apply?
We view the application of the Considerations as two-fold.  First, they supplement the existing IT-related banking regulations. Second, they are intended to apply to procurements where firms might not ordinarily consider applying FCA-originating guidelines.

Supplementing existing regulation
The preamble to the Considerations says that they are separate to, and do not replace, the existing IT-related matters that are assessed by regulators.  This means they do not replace existing Threshold Conditions and the requirements set out in Systems and Controls (SYSC) 8 of the FCA Handbook (the Handbook) - these are the general outsourcing requirements, and have been in place since 2007.  

The existing rules, as their name suggests, focus on "controls".  When firms outsource critical or important operational functions - defined as those that would materially impair a firm's ability to comply with regulatory obligations - they remain fully responsible for all those obligations. The Handbook requires compliance in a number of related areas such as reporting, audit and co-operation with the regulator, all of which must be documented as part of the outsourcing agreement.

In summary, the existing rules provide a good compliance framework of general outsourcing evaluation: have you evaluated the vendor? Can you incentivise / penalise the vendor? Can you get out of the arrangement? etc. 

Where the Considerations also concern themselves with issues of general application, there is an overlap with the existing rules.  For example, Areas of Interest such as "Oversight of service provider" and "Due diligence" are to a large degree, covered by the requirements of specific controls within the SYSC 8.1 series. 

Where the Considerations take a very different approach to the existing regulations is in their technology and sourcing specificity.  Areas of Interest such as "Multi-tenancy", "Service levels", "User Administration" and others clearly demonstrate a much greater focus on issues specific to IT procurement.  The Considerations are a "ground up" set of notes relating to issues that would need to be considered by a firm's subject matter experts, rather than a more generic set of oversight controls. 

Application to different types of procurements
Typically, firms have applied the existing IT-related banking regulation to the procurement of large-scale, "bespoke" services such as IT infrastructure and hosting services.  Buying these services has usually involved contracting on the basis of the purchasing firm's terms and conditions, and with significant involvement of the various "buying" functions e.g. IT, procurement, commercial, legal, and regulatory.

The existing rules may not have been considered as applying to off-the-shelf products, as many banking products, or many of the "as a service" type third party solutions that were not part of the IT landscape in 2007.

The Considerations are intended to specifically catch and address these types of procurements; areas of interest include "Data Segregation", "Multi-tenancy", "Track record" and "Scalability".  These are topics specific to the procurement of off-the-shelf products, often remotely hosted, and sometimes provided by new entrants to the market or relatively small providers rather than the IT megaliths.

In this context, it is no surprise that the Considerations refer to "application[s] for undertaking a new regulated business activity".  The Considerations are talking to the procurement by banks (including many of the newer financial providers, known as 'challenger banks') of core banking platforms (such as Oracle Flexcube or Temenos T24) or narrower and more specialised products such as platforms that support OTC trade reconciliations or other multi-party trading platforms.

These types of procurements may well have been subject to the existing regulations, but many times the regulations weren't considered material or relevant, and many organisations did not think too deeply about the application of regulation to these products.  Unlike outsourcing agreements, contracts for off the shelf IT products are often concluded on the vendor's paper, and the "as a service" restrictions (imposing a more restrictive business and delivery model) have acted as a blocker to negotiating some of the fundamental areas that the Considerations now require a focus on.

Firms need to approach their procurement processes for off-the-shelf platforms with a view to ensuring checks against the "Areas of interest" in the Considerations.  Applying the Considerations requires activity by most of the functions of a firm involved in purchasing and implementing such platforms, including IT, procurement, legal and others.  Additionally, the Considerations should also be thought of in the context of "traditional" material outsourcings in addition to the existing rules and guidance. 

A version of this blog first appeared in Banking Technology on 8th September 2014.

BYOD: No Such Thing as a Free Lunch

By David C. Johnson, Joshua Konvisser and Meighan E. O'Reardon

It seems intuitive that, by and large, employees prefer to use their own mobile devices, carrying only a single device for personal and work purposes, and having choice over the device to be used (please don't take away my iPhone). There has also been a hypothesis that there could be cost savings for companies that allow employees to BYOD because of the ability to defer the cost of the devices and service to the employee.

In fact, maintenance of a BYOD program (we have previously reported on legal issues surrounding Bring Your Own Device and the importance of BYOD policies), including the need to manage across non-standard devices and platforms, may actually result in a BYOD program being more costly than having a standard corporate-liable program. Add to those costs a recent California ruling that requires companies to reimburse employees for wireless service. Although the case raised more questions than it answered about what level of reimbursement is required, it seems clear that companies will bear a larger portion of the cost of BYOD programs than they had previously borne.

This is not to say that companies should abandon BYOD or that there is no business case for BYOD. However, the business case analysis now needs to take into account a different, hard cost in balancing the soft benefits of BYOD, which may be harder to quantify.

FCA warns firms on use of social media to promote financial products

By Tim Wright

The UK financial services regulator, the Financial Conduct Authority (FCA), has launched a guidance consultation in order to clarify and confirm its approach to the supervision of financial promotions in social media, including the use of character-limited forms (Examples of character-limited formats are Twitter (which limits tweets to 120 characters) and Vine (which limits videos to six-second loops).  

The FCA has identified an increase in the use of character-limited social media (and social media generally) and warned of confusion among firms over the inclusion of regulatory information such as risk warnings (in compliance with the financial promotion rules) when communicating through social sites such as Twitter, Pinterest and Vine.  And, as the FCA makes clear, every communication (e.g. each tweet, Facebook page or insertion) must be considered individually and comply with the relevant rules.

The requirement for financial products to be fair and not misleading means consumers should have an appreciation of the relevant risks (through risk warnings) as well as the benefits of a particular product.  The FCA's recommendations include not promoting more complex financial products through social media channels, and using embedded infographics to include relevant information.  The FCA also confirms that use of the hashtag #ad is an acceptable way of complying with the rule that financial promotions for investment products are identifiable as such.

The FCA does not wish to block social media use but requires firms to adhere to existing guidelines.  According to Clive Adamson, FCA director of supervision, the "FCA sees positive benefits from using social media but there has to be an element of compliance" and "financial promotions, whether on social media or traditional media, should be fair, clear and not misleading."

The FCA's consultation, which will close on 6 November this year, seeks feedback from firms on its proposed guidance. Feedback may be sent by email, or by post to Richard Lawes, Financial Promotions Team, The Financial Conduct Authority, 25 The North Colonnade, London E14 5HS.  The FCA is also planning to commission research to better understand how consumers receive, use, and contextualise financial promotions via social media communications. 

The FCA is not new to social media by any means.  It published an update on financial promotions using new media in June 2010; it has deployed teams to monitor and engage with Twitter users; and it uses's Radian6 application to mine data on social media platforms and to spot general trends.

Some of parts of the proposed guidance are also be relevant to broadcast and print media.