Sometimes even when you do things right, things can go horribly wrong.
This was never more true than in the recent Ontario case of
Business Development Bank of Canada v. Experian Canada Inc. where the Business Development Bank learned the hard way that even the most well-run procurement process cannot prevent fraud.
Seeking to replace its existing commercial lending software system, BDC issued a detailed request for information in early 2008. Experian Canada Inc. and Experian Information Solutions Inc. (collectively Experian), responded to BDC’s request and was eventually chosen on the basis that Experian’s solution allegedly had the “best fit for BDC’s needs.” BDC signed a software development, implementation, license and support agreement on March 27, 2009 whereby Experian agreed to provide a new commercial lending software system based on Experian’s existing relationship lending suite.
The RLS implementation and business relationship failed completely, and BDC terminated the agreement on Nov. 19, 2009. BDC sued Experian, seeking damages for fraudulent misrepresentation and breach of contract (including millions in incremental costs and loss of net economic benefits caused by the delay in implementing the new system), and punitive damages for deliberately misleading. Experian counterclaimed for damages, i.e. the monies that BDC owed it under the agreement that remained unpaid. In the interim, BDC created its own lending system through a combination of custom software and commercially available software that was implemented in June 2014.
The basis of the case involves the considerable dichotomy between what BDC thought it was purchasing from Experian and what Experian actually intended to deliver. BDC claimed that it had selected Experian because of its written and oral representations regarding RLS. RLS was supposedly a proven, mature “out of the box” technology used by over by 1,100 financial institutions, including two non-US banks. With a broad customer install base, BDC understood RLS would be maintained and evolve as a whole for all customers using the product so that BDC would receive upgrades such as bug fixes and future releases in the normal course (Experian claimed the product had two releases per year, one functional and one for bug fixes). Experian’s own response to the RFI claimed the “base code” of RLS already contained much of the critical functionality required by BDC, complying with the 700 requirements BDC had requested in its RFI. Additional BDC requirements would be met by configuring the RLS base code and certain (minimum) customization. Experian represented that it had the skill and experience to implement RLS in BDC’s environment in accordance with BDC’s timelines.
However, the court found the actual facts to be quite different, as follows:
- While Experian did have a base version of RLS that had been installed at two international banks, it was in the process of developing a new version of its lending software, RLS 5.1, which was not fully tested (it was later revealed to be extensively bug-ridden). Experian did not reveal that it had responded to BDC’s RFI on the basis of the new version of its RLS software, not its production version. BDC’s own employees confirmed they expressly did
not want to purchase untested “bleeding edge” software because it was deemed too risky in the lending area, BDC’s “bread and butter,” but this is exactly what Experian had planned to make available to BDC based on its responses to the RFI. Experian’s answers to the technical questions in the RFI in which Experian gave itself high scores led BDC to believe it had an existing product but at the time no customer was using RLS 5.1 as it was not a completed product or actually deployable at the time.
- Experian blatantly claimed its existing software typically met “85 per cent of the client’s needs — 15 per cent customization” and stated its software had an 81 per cent functional fit with BDC’s requirements. Since there was no “as is” version of RLS 5.1, this was completely untrue. BDC later calculated that the actual functional fit of the Experian software was only 46 per cent and had they known this BDC would not have selected Experian.
- Experian gave BDC a demonstration of its software in May 2008. BDC was impressed with the software, although Experian later revealed it was not clear what it actually showed to BDC’s employees during the demonstration. However, the demonstration helped seal the deal. At no time did Experian distinguish between the software that they were demonstrating and the lending software actually in use by their existing clients.
- Unknown to BDC, in November 2008 Experian was in the process of developing a version of RLS for the National Australia Group of Europe, an international bank operating in the United Kingdom. Experian made a business decision to stop its development work for BDC, instead focusing its resources on the software for NAGE. Experian planned to use some of the NAGE code as a base product for BDC, assuming that in the meantime elements of the agreement relating to the fit/gap analysis phase could be pursued. BDC found that it was practically impossible to conduct a meaningful fit/gap analysis as Experian had not even provided a base “vanilla version” of its software, further delaying the project. Even worse, the NAGE software under development by Experian was found to be full of bugs, which meant that it could not be used for the BDC implementation, separate and apart from the question the two implementations had different requirements.
Ultimately BDC terminated the agreement on November 19, 2009 after Experian advised it would charge BDC $13.09 million to implement the promised software, taking an additional 18 months to deliver a product that would meet all of BDC’s requirements.
Red flags
BDC’s RFI included detailed requirements, a separate vendor questionnaire background document that explained how vendors should interpret the RFI questions and BDC had asked the three short-listed vendors to assess their own products, conducted demonstrations, held workshops and had ongoing discussions with their selected vendor. Could BDC have reasonably done anything different? For the most part, the red flags appeared after BDC had signed the agreement, but some of Experian’s behaviour should probably have made BDC pause.
No documentation
As early as February 2009 BDC had requested that Experian provide it with a user manual for the software, which should have been easy if Experian actually had an existing base product. However, since Experian was in fact still in the process of actually drafting the RLS 5.1 manual, Experian repeatedly stalled on this ask and told BDC that they could not review the manual until after the agreement was signed. Thereafter, BDC continued to press with no avail and surely this should have been a neon sign that Experian refused to meet this most basic request.
No sandbox/No escrow
Under the agreement BDC was obliged to immediately pay Experian license fees for the so-called “base product” while Experian worked on formal specifications to customize it to meet BDC’s specific requirements by June 2009. Experian was supposed to deposit into escrow the source code for the base product five days after BDC signed off on these formal specifications. After executing the agreement, BDC reasonably asked Experian to provide it with a “vanilla” or “sandbox” version of the RLS software as a base version so that BDC could get started on data conversion, look at the RLS database and help with change management efforts. Experian refused to provide this or any code even after repeated BDC requests made over many months. Experian finally admitted to BDC that there was no base code in June, 2009, months after agreement signature.
Salvation: The limitation of liability clause
Thanks to some skilled lawyering on the part of BDC’s counsel, the agreement contained a limitation of liability clause that did not exclude or restrict liability “resulting from fraud.” The clause also contained language that stated contact damages were limited to direct damages only, excluding losses caused in any way by acts, omissions or misrepresentations (but excluding “any fraudulent or negligent misrepresentation” committed in connection with the agreement). Justice Glenn Hainey ultimately found that the limitation of liability clauses did not apply to BDC’s claims based on Experian’s fraudulent misrepresentations and breach of contract and therefore did not preclude or limit any damages award on these grounds.
Smoking emails
It certainly didn’t help Experian’s defense that various employees and executives left a smoking internal email trail where they admitted they pulled critical resources away from BDC to source the NAGE deal, that their own software code was “garbage” and “riddled with bugs and issues” and that it could not be used as a “stable starting point for BDC.”
Resolution
Based on the egregious facts in this case, it comes as no surprise that the court ultimately concluded Experian made fraudulent misrepresentations regarding its software and capabilities to BDC in order to induce BDC to choose Experian as its winning vendor. The court also found BDC had wasted 15 months in its goal to implement a more efficient lending software because it would never had entered into the agreement had it known what software Experian could actually deliver. Concluding that Experian had breached the agreement with BDC, Hainey therefore allowed BDC’s claim for damages arising from Experian’s fraudulent misrepresentations and assessed damages in the amount of $44,447,416 plus pre-judgment and post-judgment interest, signaling that Ontario courts have no sympathy for fraudulent vendors that seek to abuse fair procurement processes.
