CITATION: Business Development Bank of Canada v. Experian Canada Inc., 2017 ONSC 1851

COURT FILE NO.: CV-10-405324

DATE: 20170323

ONTARIO

SUPERIOR COURT OF JUSTICE

BETWEEN:

BUSINESS DEVELOPMENT BANK OF CANADA

Plaintiff

– and –

EXPERIAN CANADA INC. and EXPERIAN INFORMATION SOLUTIONS, INC.

Defendants

AND BETWEEN:

EXPERIAN CANADA INC. and EXPERIAN INFORMATION SOLUTIONS, INC.

Plaintiffs by Counterclaim

– and –

BUSINESS DEVELOPMENT BANK OF CANADA

Defendant by Counterclaim

Benjamin Zarnett, Peter Ruby, and Peter Kolla for the Plaintiff, Business Development Bank of Canada

Gervas W. Wall, Lauren Lodenquai and David Bowden for the Defendants, Experian Canada Inc. and Experian Information Solutions, Inc.

HEARD: April 18, 19, 20, 21, 25, 26, 27, 28, May 2, 3, 9, 10, 11, 12, June 6 and 23, 2016

REASONS FOR JUDGMENT

HAINEY J.

Overview

[1] This is an action by the Business Development Bank of Canada ("BDC") against Experian Canada Inc. and Experian Information Solutions, Inc. (collectively "Experian") for damages for fraudulent misrepresentation and breach of contract. Experian has counterclaimed for damages it alleges BDC owes to it.

[2] The proceedings arise from a Software Development, Implementation, License and Support Agreement entered into by the parties on March 27, 2009 (the "Agreement"). Under the Agreement, Experian was to provide BDC with a new commercial lending software system.

[3] In early 2008, BDC decided to find a replacement system for its existing commercial lending software system. BDC conducted a procurement process with the assistance of LGS Group Inc. ("LGS"), an information technology consultant that is a subsidiary of IBM. With the assistance of LGS, BDC selected Experian as one of the potential suppliers.

[4] Experian actively participated in BDC's procurement process beginning in April 2008. As part of that process, Experian responded to BDC's extensive Request for Information ("RFI"). Because of representations made by Experian in its response to BDC's RFI and other representations made by Experian's employees during the procurement process about Experian's lending software, BDC entered into the Agreement with Experian to provide BDC with a replacement software system.

[5] The implementation of the new software system, which began after the Agreement was signed in March 2009, did not go well. As a result, on November 19, 2009, BDC terminated the Agreement with Experian.

[6] BDC then created its own lending software system using a mix of commercially available and custom software. This new software system, called CLICS, was implemented by BDC in June 2014.

[7] BDC alleges that Experian fraudulently misrepresented the characteristics of the lending software system it could deliver to BDC. In particular, BDC alleges that Experian represented that the software system it proposed to implement at BDC currently existed as a base product, with certain characteristics described in Experian's response to BDC's RFI, when it did not. BDC submits that Experian thereby made fraudulent misrepresentations and breached the Agreement.

[8] BDC's claim for damages against Experian is for the incremental costs it incurred because of its unsuccessful dealings with Experian and for its loss of net economic benefits caused by the delay in implementing new lending software.

[9] Experian's counterclaim is for Development Charges under the Agreement that BDC has refused to pay.

The Parties

[10] BDC is a Crown corporation. Its statutory purpose is to support Canadian entrepreneurship by making loans and providing consulting services to small and medium-sized businesses. Its head office is located in Montreal, Quebec.

[11] Experian Information Solutions, Inc. ("Experian US") is a US company with its principal place of business in Costa Mesa, California. Experian US licenses and implements computer software, and provides services to organizations to help manage their commercial and financial decisions. Experian US acquired Baker Hill in 2005. Baker Hill originally developed commercial lending software which it called its Relationship Lending Suite ("RLS"). Following its acquisition by Experian US, Baker Hill became the division of Experian US responsible for its RLS software. Experian proposed to provide RLS to BDC.

[12] Experian Canada, Inc. ("Experian Canada") carries on the same business as Experian US in Canada. Its principal place of business is Toronto, Ontario.

The Trial

[13] The trial lasted sixteen days. BDC called the following witnesses:

• Anne Boutin – Ms. Boutin was the National Director of BDC's Agility and Efficiency Program ("A&E Program") from 2008 to 2012. The A&E Program sought to update BDC's technology by replacing its existing lending software system and by updating its websites and its record and document management systems. Ms. Boutin testified about her involvement in all aspects of the A&E Program and her extensive dealings with Experian throughout its efforts to replace BDC's lending software. She explained why BDC selected Experian to supply the new software and why it entered into the Agreement. She also described the problems that ensued between BDC and Experian leading up to BDC's termination of the Agreement.

• Brian Eatock – Mr. Eatock, formerly a senior management consultant with IBM, testified about his role as the leader of the LGS team hired by BDC to assist with its acquisition of new lending software. He testified about Experian's representations to BDC about its RLS software and why BDC chose Experian to supply its new lending software.

• Chantal Belzile – Ms. Belzile was BDC's Vice President, Information Technology during BDC's dealings with Experian in 2008 and 2009. She testified about her responsibility for the A&E Program and her dealings with Experian during the "fit/gap" analysis when Experian tried to adapt its software to meet BDC's needs during 2009.

• Edmée Métivier – Ms. Métivier was BDC's Senior Vice President, Finance and Consultation, from 2006 until 2012. She testified about why BDC's Board of Directors made its decisions regarding the A&E Program. In particular, she testified as to why BDC chose Experian to supply the new software and the problems that ensued with Experian's efforts to implement its software at BDC.

• Eric Marineau – Mr. Marineau was BDC's Lead Business Architect for the A&E Program from 2007 to 2013. He testified about what he expected of Experian's staff and his assessment of their competence and ability to deliver to BDC what Experian had promised. In particular, he testified about the lack of knowledge on the part of Experian's employees about Experian's RLS software and their inability to provide a current version of the RLS software to BDC when requested to provide one.

• Eric Carrière – Mr. Carrière was BDC's Business Analyst on the A&E Program. He was involved from the inception of the A&E Program until 2003. He testified about the benefits of using the CLICS lending software system eventually implemented at BDC.

• Pierre Dubreuil – Mr. Dubreuil became BDC's Senior Vice President, Finance, following Ms. Métivier's retirement at which time he assumed responsibility for the A&E Program. He testified about the benefits to BDC of the CLICS system.

• Stefano Lucarelli – Mr. Lucarelli was BDC's Vice President, Finance, from 2007 to 2012, after which he became Senior Vice President, Finance, and BDC's Chief Audit Executive. He testified about the expected benefits to BDC of the new lending software and the damages BDC suffered as a result of Experian's misrepresentations and breach of the Agreement.

• Professor Gail Murphy, Ph.D. – Professor Murphy is a professor of computer science at the University of British Columbia. She was qualified as an expert witness to give opinion evidence about software engineering. She testified that Experian did not have a base product for the lending software it proposed to provide to BDC.

• Howard N. Rosen – Mr. Rosen, who is Senior Managing Director of FTI Consulting Canada ULC, was qualified to give expert opinion evidence in the quantification of economic damages. He testified about the economic damages that BDC suffered as a result of Experian's fraudulent misrepresentations and its breach of the Agreement.

[14] Experian called the following witnesses:

• Christopher Daily – Mr. Daily was Experian's Program Director for its project with BDC. He was Anne Boutin's counterpart and had ultimate responsibility for delivering the new lending software BDC had contracted for. He testified about all aspects of Experian's project with BDC including its representations to BDC and his extensive discussions with Ms. Boutin.

• Vijay Mehta – Mr. Mehta was Experian's Chief Architect on its project with BDC. He reported to Mr. Daily. He was responsible for defining Experian's overall technical strategy for the BDC project. He testified about the technical aspects of Experian's products and the events that occurred with BDC.

• Bill Busch – Mr. Busch was Experian's Chief Salesperson for its lending software that it proposed to provide to BDC. He testified about the representations he made to BDC during the sales process and the negotiations leading up to the Agreement.

• Michael Jackman – Mr. Jackman was qualified as an expert witness to give opinion evidence about application software development and sales and implementation, in particular, as that software relates to the lending industry.

• Mark Gain – Mr. Gain, of Matson Driscoll & Damico Ltd., was qualified as an expert witness to give opinion evidence on the quantification of economic damages. He provided a critique of Mr. Rosen's opinion and gave his own calculation of BDC's economic losses.

[15] I refer to the evidence of certain of these witnesses in more detail below.

The Issues

[16] The issues I must determine in this case are as follows:

1. Did Experian make fraudulent misrepresentations regarding its software or its capabilities to BDC and, if so, did BDC rely on the misrepresentations in a manner that caused it damage?

2. Did Experian breach the Agreement with BDC?

3. What is the effect of the limitation of liability clauses in the Agreement?

4. If Experian is found to be liable for fraudulent misrepresentation or breach of contract, or both, what is the proper measure of damages?

5. Is Experian entitled to the payment of one-half of the outstanding Development Charges under the Agreement?

Positions of the Parties

BDC's Position

[17] BDC's central allegation against Experian is that it was induced by Experian's misrepresentations about its lending software to deal with Experian and to eventually enter into the Agreement to acquire Experian's lending software. According to BDC, if Experian had not made these misrepresentations, BDC would not have spent the time and expense it did dealing with Experian and BDC would not have entered into the Agreement.

[18] According to BDC, Experian made the following representations regarding its RLS software:

• It existed as an "out of the box" base product.

• It was used by over 1,100 financial institutions including two non-US Banks.

• It had evolved as a whole and would continue to so evolve. Experian's RLS software had certain specific functionalities and characteristics detailed in Experian's response to BDC's RFI.

• It was adaptable to BDC's needs with minimal customization.

• Experian had the skill and experience to implement the RLS software in BDC's environment and within BDC's timeline.

[19] BDC submits that none of these representations were true. Experian did not have the software it said it did, with the attributes it said its software had. It only had the hope of developing such software in the future. According to BDC, Experian misrepresented, knowingly and intentionally, that it had a software product that currently existed when it did not.

[20] Because it became clear to BDC in the fall of 2009 that Experian could not deliver on its representations and perform the Agreement, it terminated its dealings with Experian. BDC then had to recommence steps to obtain the new lending software it required. BDC experienced an 18-month delay in achieving the benefits it should have had earlier if Experian had lived up to its representations and had not breached the Agreement.

[21] BDC submits that it suffered damages, as a result of Experian's fraudulent misrepresentations and breach of the Agreement, of approximately $57 million for its incremental costs of dealing with Experian and its loss of net economic benefits from the 18-month delay it experienced in implementing new lending software. BDC also seeks punitive damages of $500,000 against Experian because BDC alleges that Experian deliberately misled it throughout their relationship, evidenced by Experian's motto on the project of "fake it until we make it."

Experian's Position

[22] Experian submits that BDC has failed to establish that it made any misrepresentations of fact. When BDC first contacted Experian it had its RLS base product that had been installed at two international banks. It also had a new version of its lending software, RLS 5.1, which had been designed but not fully tested. It was on the basis of this new version of its RLS software that Experian responded to BDC's RFI.

[23] Experian further submits that it did not make any false statements to BDC or LGS with knowledge that the statement was false either during the procurement process or during the project itself. According to Experian, none of its employees represented that Experian's hundreds of customers in the US were using the RLS software that Experian proposed to implement at BDC. Experian maintains that it became clear to BDC from June through September 2008 that what Experian intended to license to BDC was a software system that had been developed for banks outside of the US. Experian submits that it was clear to BDC that this was a different software system than the system being used by its US bank customers.

[24] Experian maintains that it responded to BDC's RFI truthfully by providing information about the version of RLS software it "was seeking to install at BDC." According to Experian, it "expected to install RLS at BDC only after the necessary specifications were identified by the parties and the customizations built as part of the development process."

[25] Experian further submits that BDC may have misinterpreted information about Experian's RLS software from information it obtained through third parties or on its own. According to Experian, "In summary, regardless of how BDC used or interpreted information provided by Experian or through other parties during the procurement process, Experian made no misrepresentation, and made all representations in the honest belief that they were true."

[26] Experian has counterclaimed to recover one-half of the outstanding Development Charges, which it alleges BDC is obligated to pay as a result of its decision to terminate the Agreement. Experian submits that it fulfilled its obligations under the Agreement and is, therefore, entitled to payment of this amount.

Factual Analysis

BDC's Expectations

[27] Ms. Boutin testified that BDC participated in a survey of financial institutions in 2006. The results of the survey demonstrated that BDC ranked relatively low because its processes to make and administer loans took too much time. At the time BDC was using a custom-built computer lending system called CREM Manager. This system was difficult to evolve and expensive to maintain. Because the software had been developed for BDC alone, BDC did not benefit from other financial institutions' experience with the software or from improvements to the software that BDC did not initiate itself.

[28] According to Ms. Boutin, BDC wanted to improve this situation and determined that its existing software had to be replaced. In January 2008, BDC embarked upon its A&E Program to update its technology and, in particular, to replace its lending software.

[29] Ms. Boutin explained that BDC wanted to make its employees more productive by providing them with an improved lending software system.

[30] BDC retained LGS to assist BDC in defining its requirements for new lending software and to select the appropriate software vendor. Ms. Boutin described the type of lending software that BDC wished to acquire as follows:

• The software had to fit as closely as possible to the approximately 700 requirements BDC had developed with LGS.

• The software had to have been run by many other customers over several years.

• The software was to be maintained and evolved as a whole for all the customers using it so that BDC would receive upgrades such as bug fixes and future releases.

• The software had to be adaptable to BDC's needs through configuration and customization.[^1]

[31] BDC believed that this type of software would be lower cost and higher quality than custom built software. According to Ms. Métivier:

So management at the bank, over time, had simply made up its mind that it was in the best interests of the organization to not build internally software, but actually buy a package, a package that would not be bleeding edge, a package that had been tested in other organizations, a package that could - or a package or a software that could evolve with time.

So basically what we wanted to do is transfer the risk of updating the package to a supplier and not have that internally.[^2]

[32] According to Ms. Boutin, when Ms. Métivier said that BDC did not want a software package that was "bleeding edge" she understood her to mean as follows:

Bleeding edge means, to me, a solution that's used by very few, tested by very few, and you're kind of a guinea pig for the vendor when running a solution like that.[^3]

[33] She explained that BDC was not interested in bleeding edge technology because:

Too much risk, really. Lending was and is BDC's bread and butter. So it would have been too much risk.[^4]

[34] According to Ms. Boutin, BDC's employees referred to the characteristics they wanted in their new lending software interchangeably as "base software," "base solution," "base" and "out of the box."[^5] Experian's employees used the same terms and understood what BDC's employees meant by these terms.

[35] Mr. Eatock described the directions he received from BDC about the new lending software it wished to acquire as follows:

… I began by interviewing the BDC leaders in the A&E core and the business sponsors to understand their objectives in terms of what they wanted to do with their business what - was the transformation boundaries, what were they trying to achieve.

And what they told me was that they - they didn't want to add to their business with technology. What they wanted was they wanted a mature technology that was proven; that was implemented; that fit with their needs, but they were not interested in any early-stage experimentation. They weren't interested in vendors that wanted to change the business with technology.

What they wanted was a proven, established product with a large install base, and they wanted it tightly fit against their needs, and they wanted to minimize any customization. To the extent possible, they wanted the software that they used on the lending platform to be out of the box.

And out of the box is - it's a funny term, but, you know, software used to be sold in shrink wrapped boxes, and out of the box meant you took the plastic wrapper off it, and you opened it up, and you stuck the floppy disk into your computer and it would run.

So out of the box conveys a similar level of maturity in that the product exists; it's standardized; and you can implement it with minimal customization.

So why would you do that? You want to do that in order to minimize the risks in the project, use established technology from mature vendors.[^6]

[36] Mr. Eatock summarized the characteristics that BDC wanted in its new software as follows:

On the lending software, BDC was looking for established, mature vendors. They were looking for a significant install base. …they were not looking for new entrants in terms of commercial lending software with very few installs. They didn't want to take the risks involved. And they felt their business was best served with a mature, established product.

There's also a tremendous benefit from a standardized product. So if you have a large install base, the only way in which you can operate effectively is to standardize your product.

If every one of your customers has a unique instance of the product, it creates a huge burden to keep the product up to date. You would have to update every single instance separately. So a standardized product has a huge advantage for companies in terms of selecting packaged software.

And then keeping the product up to date, it provides a couple of things. It provides the feedback from a user community so that the vendor is always sort of in tune with where the industry is going. And then, as standard releases of improvements are rolled out, the user community, if you have a large user community, they share the costs of that. So the costs for each licensee is much lower than if they have a unique custom solution.

Customization was to be minimized and only to be entertained if there was a business case for customization. To the degree possible, we were looking for a standard product with a high fit against functional and nonfunctional requirements of the company and an ability to get it implemented with configuration, which is a much less expensive and less difficult or risky requirement to get something implemented.[^7]

[37] Having received these directions from BDC, Mr. Eatock reduced a long list of potential vendors to a medium-sized list which included Experian. He testified that he eliminated vendors from the list who did not have "a significant install base." He said "If they had two or three installs or five installs, we would have just eliminated them."

[38] On all of this evidence I find that BDC's employees wanted to acquire mature, standardized, out of the box software that was being used successfully by a number of other financial institutions and did not require much customization.

Experian's Initial Representations to BDC

[39] After the list of potential software vendors had been reduced to a medium-list, Ms. Boutin and Mr. Eatock prepared a list of questions in a Vendor Pre-Qualification Questionnaire. According to Ms. Boutin the purpose of the questionnaire was as follows:

We were trying to get, at a high level, a first look at those medium-list vendors and getting a little bit more detail. But mainly we wanted to find out those who had a base solution or base package.[^8]

[40] Two of the questions in the questionnaire were the following:

1. Commercial Lending: Do you support Commercial and Small Business Lending? How many customers do you have?

2. Out of the Box Functionality: Do you offer an out of the box packaged solution vs. a Framework (toolsets)?[^9]

[41] BDC and LGS then had telephone calls with the medium-list vendors to go over the questionnaire.

[42] On April 28, 2008, Mr. Eatock and Ms. Boutin had a telephone conversation with Bill Busch. Mr. Busch said the following to Ms. Boutin and Mr. Eatock about Experian's RLS lending software product:

• Experian had more than 1,100 clients, mostly in the US but with a couple internationally;

• Regarding "out of the box," Experian's product can be installed and it would work. "Large organizations are using it;"

• Experian had seen an 85% to 90% fit with their customers' requirements;

• Experian's product had two releases per year, one functional and one for bug fixes;

• RLS was "a version of our standard software" and a "base." Mr. Busch noted that Experian's software delivered over the internet, called the ASP model, was the "same software, just configurable."[^10]

[43] Mr. Eatock's testimony of what he and Ms. Boutin took away from their telephone conversation with Mr. Busch was as follows:

Okay. So what I took away from it was that Baker Hill was a mature company and a qualified vendor. It had a large install base. It had a standardized product. And they were confident that they had a product that would have a very high fit against the requirements to run a commercial business. So it was a very confident, clear one-hour discussion.

What we heard was that they had a very large install base of a standardized product. The company was in this business for many years. It knew the business intimately. It was delivering to this large install base and keeping it current. So it must have had a lot of discipline in its culture in terms of delivery. And it was quite mature.[^11]

[44] Mr. Eatock explained that his staff scored all of the responses of the medium-list vendors given during the telephone conversations and came up with a short-list of three companies which included Experian. He testified that Experian made it to the short-list of potential vendors because "of their install base and their high functional fit and their knowledge of the business and the breadth and depth of the product."[^12]

Experian's Response to BDC's RFI

[45] BDC and LGS then prepared an RFI that included a spreadsheet listing 700 requirements that BDC wanted for its new lending software and questions about the vendors' product. BDC also prepared a Vendor Questionnaire Background document that explained how vendors should interpret the questions in the RFI and fill out the spreadsheet. According to Ms. Boutin, BDC wanted the three short-listed vendors to assess their own products against BDC's list of requirements.

[46] The Vendor Questionnaire Background document, that was provided to Experian, contained the following instructions on completing the questionnaire in the RFI:[^13]

4.2 Instructions on Completing the Questionnaire

For functional requirements, the questionnaire will require you to rate/assess a feature as well as to capture any relevant comments under the "Vendor Comments". When answering a question please follow these instructions.

Vendor Rating

Complete the "Vendor Rating" column. Descriptive responses should be made in the excel spreadsheet. You can attach document with your response with a precise reference (i.e. see Document_name, Page #, Paragraph #). Response values will indicate the following:

Vendor Self Assessment Rating	Description
"5 – This feature is standard functionality of our product"	Your solution fully meets the requirement without customization (i.e. out of the box with no code changes or any type of development effort is required) or application parameters setting.
"4 – This feature can be supported by configuration"	Your solution fully meets the requirement without customization (i.e. no code changes or any type of development effort is required) although application parameters may have to be set.
"3 – Add On by Third Party"	Your solution can meet requirement by the addition of a Third Party component which integrates with your solution. Use the area "Vendor Comments" to explain.
"2 – This feature provided by a port and re-test of app."	Your solution can meet the requirements but requires some code changes or any type of development effort. Briefly describe the change required in the question "Vendor Comments" area beside the corresponding question.
"1 – This feature requires programming"	Your solution can meet the requirements but requires some code creation or any type of development effort. Briefly describe the code required in the question "Vendor Comments" area beside the corresponding question.
"0 – This feature cannot be accommodated"	Your solution cannot meet the requirements even with some code creation or any type of development effort.

Effort Required to Enable

Please complete the "Effort Required to enable (FTE)" column. Use "Vendor comments" area to precise your answer. FTE stands for "Full Time Equivalent". Response values will indicate the following:

Vendor Self Assessment Rating	Description
"5 – This feature does not require any effort to enable"	Your solution provides this feature without any additional effort once the software is deployed.
"4 – This feature can be enabled within an hour"	Your solution provides this feature with an additional effort of an hour or less once software is deployed. Identify in comments the type of effort require (IT / Business Analyst / End user)
"3 – This feature can be enabled within a day or two"	Your solution provides this feature with an additional effort of up to 2 days once software is deployed. Identify the type of effort require (IT / Business Analyst / End user)
"2 – This feature can be enabled within a week or two"	Your solution provides this feature with an additional effort of up to 2 weeks once software is deployed. Identify the type of effort require (IT / Business Analyst / End user)
"1 – This feature can be enabled within a month"	Your solution provides this feature with an additional effort of up to a month once software is deployed. Identify the type of effort require (IT / Business Analyst / End user)
"0 – This feature requires more than a month to enable"	Your solution provides this feature with an additional effort of more than a month once software is deployed.
"N/A – This feature is not applicable to an effort estimation"	Applicable where no effort can relate to the question.

[47] As can be seen from these instructions, Experian was asked to evaluate its software product with reference to BDC's requirements and to advise BDC of the extent to which its software met each requirement using a scale of 1 to 5. Experian rated its software as either a 4 or 5 for most of BDC's requirements.

[48] Based upon these instructions, if Experian provided a score of 5 under "Vendor Rating" this meant that Experian was representing to BDC that the specified feature of its lending software "fully meets the requirement without customization (i.e. out of the box with no code changes or any type of development effort is required) or application parameters setting." If Experian provided a score of 5 under "Effort Required to Enable," this meant that Experian was representing to BDC that the specified feature of its lending software "provides this feature without any additional effort once the software is deployed."

[49] If Experian provided a score of 4 under "Vendor Rating," this meant that Experian was representing to BDC that the specified feature of its lending software "fully meets the requirement without customization (i.e. no code changes or any type of development effort is required) although application parameters may have to be set." If Experian provided a score of 4 under "Effort Required to Enable," this meant that Experian was representing to BDC that the specified feature of its lending software "provides this feature with an additional effort of an hour or less once software is deployed."

[50] Experian did not ask BDC for clarification of either the instructions or the questions in the RFI.

[51] Experian provided BDC with its response to the RFI on May 22, 2008 with a cover letter from Mr. Busch that stated, in part, as follows:

More than 1,200 financial institutions in all segments have drawn on our expertise to improve key processes, and have chosen our relationship management, credit origination, statement analyser and portfolio risk management solutions as their enabling technologies.

The Baker Hill Solution is a browser-based business process solution designed to help banks better manage and enhance client relationships and credit approval processes across lines of business. Our solution is made up of integrated components …

Baker Hill's solutions are available now and are fully supported and maintained by our company. We are a 'solution' company and our clients, over 1200 to date, define the functionality available in our products. …

The financial industry continues to evolve and it is important to select a software partner that will focus on specific business requirements. We appreciate the fact that when possible, financial institutions want to provide off the shelf software tools to their users as quickly as possible rather than endure a long development project. This strategy will allow Bank of Canada to receive updates and stay current with technology and functional changes.[^14]

[52] Ms. Boutin testified that she understood from Mr. Busch's letter that Experian's lending software was a base solution that had been implemented before with other customers. I accept Ms. Boutin's evidence. This is a reasonable interpretation of Mr. Busch's letter.

[53] The following are certain of Experian's responses to BDC's RFI:[^15]

GI-05

General Information

Has your product been deployed in Canada? If yes, please elaborate.

No.

GI-06

General Information

What experience does your organization have within the financial services industry (and in commercial lending in particular)?

For more than two decades, Baker Hill has been focused on the financial services industry, delivering solutions that address business process needs and working as a trusted advisor to our clients. More than 1,200 financial institutions in all segments have drawn on our expertise to improve key processes, and have chosen our relationship management, credit origination, and portfolio risk management solutions as their enabling technologies.

GI-07

General Information

What experience does your organization have with mid-tier business banks such as our own.

The majority of Baker Hill's relationships are with mid-tier business banks.

GI-10

General Information

Please describe the installed base of your product.

The Baker Hill Solution (RLS) is a browser-based, business process solution designed to help banks better manage and enhance client relationships and credit approval processes across lines of business. Our solution is made up of integrated components which provide the following functionality: Sales and relationship management, financial spreading and analysis, pricing and profitability across the relationship, document, policy, compliance and exception management and origination processing. RLS consolidates all client and prospect information into a single solution that can be shared across the enterprise.

Please refer to following attachments:

-Client_Advisor.pdf

-Exception_Advisor.pdf

-Portfolio_Risk_Advisor.pdf

-RLS Overview.pdf

-Statement Analyzer.pdf

14.01

ASP Hosted Model

Is your product offered in an ASP model?

Yes.

14.02

ASP Hosted Model

How many customers do you host using an ASP model? Current and planned?

310 clients.

16.10

Software

How many different databases do you use?

The system stores all application data in a single database. There are additional ancillary databases that store metadata for other application components depending on the features and components deployed. All of these databases reside on SQL Server.

CS 1.01

What is the estimated cost of implementation? This should include installation, system configuration, average cost per interface, etc.

While it is difficult to determine the exact cost of the solution deployment, a typical rule of thumb for us has been 1.5 x to 2.5 x of license fees. This is very dependant on the number of interfaces and the required amounts of customization. Our experience has been that the "as is" solution will typically meet 85% of the clinets' [sic] needs – 15% customization.

[54] Mr. Daily testified that he was responsible for Experian's response to BDC's RFI. He explained that he and his team answered the questions in BDC's RFI on the basis of Experian's new version of its lending software, RLS 5.1, which was in development at the time. He agreed with the following about Experian's response to BDC's RFI:

• "product" or "the Baker Hill solution" are references to version RLS 5.1 of Experian's lending software.

• Everyone on the Experian team, including Mr. Busch, were aware of the status of version RLS 5.1. It was not completed and not deployable at the time when Experian responded to BDC's RFI.

• At the time, no customer was using version RLS 5.1 and it was not ready for general availability to customers as a base release.[^16]

[55] Mr. Daily confirmed that certain of Experian's responses to BDC's RFI were not correct when he was cross-examined as follows:

Q. 'Please describe the installed base of your product.' Was the question. And the answer does not include that RLS 5.1 was not deployed or deployable, does it?

A. We did not answer the question correctly, or we did not answer the question-with my current understanding of this, this answer doesn't match the question.

Q. And when the answer says: 'RLS consolidates all client and prospect information into a single solution that can be shared across an enterprise.' RLS 5.1 wasn't consolidating any clients' information or any prospects' information for a financial institution or sharing it across any financial institution's enterprise on May 22, 2008; correct?

A. That's correct. It was still in development.

Q. All right. And when you say it wasn't answered correctly, you mean the answer should have been, 'We haven't installed this yet'; correct?

A. Yes. That would have been the way I would have answered it.

Q. And that would have been important for BDC to know?

A. Yes, it would. I would have also expected that it would have been clarified in the review of the RFI with both IBM and with BDC.

Q. Now, sir, you never went to BDC and specifically revised any part of the RFI. Am I right?

A. I don't remember doing that.[^17]

[56] Mr. Daily also admitted under cross-examination that Experian had no experience with RLS 5.1 in terms of meeting any client's needs, yet in its response to BDC's RFI, Experian responded "Our experience has been that the 'as is' solution will typically meet 85% of the client's needs – 15% customization."[^18]

[57] Mr. Daily was also cross-examined on the fact that Experian had provided scores of 5 in its response to BDC's RFI in respect of many of BDC's requirements suggesting that the software currently had the specified characteristics. He testified as follows:

Q. … On May 22, 2008, was it accurate to say RLS 5.1 provides this functionality to customers?

A. We were answering this RFI based on the functionality that we had in development at the time.

Q. Perfect. So functionality you hoped would be achieved when RLS 5.1 was complete?

A. Yes.

Q. All right. So just so we're clear, when we see the present tense in the question – 'This feature is standard functionality.' – what you're saying is you meant, 'This feature will be standard functionality when we get finished'; correct?

A. I didn't answer this specific question, so it wasn't me who said that. But my team would have answered it this way.

Q. Well, sir, did they ask you for any approval to use the present tense to describe something that may occur in the future, but was not currently existing?

A. No.[^19]

[58] Mr. Mehta, who testified that he was responsible for certain of Experian's responses to BDC's RFI, also said that he was referring to RLS 5.1 in his responses to the RFI. Although Mr. Busch claimed to be unaware of the state of the development of RLS 5.1, Mr. Daily testified that Mr. Busch was also aware that it was still in development and not a completed product.

[59] It appears clear that Mr. Daily answered BDC's questions about Experian's lending software on the basis of what he hoped version RLS 5.1 would someday be, not what it was when Experian responded to BDC's RFI. I find that this was misleading. My conclusion is based, in part, upon the following:

• Experian's answer that its product was not deployed in Canada was only half true and thereby misleading. In fact, RLS 5.1 was not deployed anywhere and was not deployable when Experian provided its response to BDC.

• Experian's answer to BDC's question about its "experience" with financial institutions is misleading without clarifying that none of BDC's banking customers were using version RLS 5.1 of its lending software.

• Experian's answer to BDC's request to describe "the installed base of your product" is misleading because at the time RLS 5.1 was not a base product and it was not and could not be installed anywhere.

• Experian's answer that RLS 5.1 was available in an ASP model and that 310 clients were hosted using an ASP model was not a true statement about version RLS 5.1. It was not available in an ASP model and it was not being used by any of Experian's customers.

• Experian's answer about RLS 5.1, "Our experience has been that the 'as is' solution will typically meet 85% of the clients' needs – 15% customization," is not a true statement since there was no "as is" product and there could be nothing "typical" about the installation of the software since it had never been installed.

• Experian's answers to the hundreds of technical questions in the RFI in which it provided a score of 4 or 5 clearly suggested to BDC that there was an existing product. This was misleading because the software did not exist and was only being developed at the time.

[60] On all of the evidence, I find that during this procurement phase, Experian's key employees were aware that RLS 5.1 was only in the development stage and did not have the characteristics it was represented to have in Experian's response to BDC's RFI. Further, I find that it was well known to Experian's key employees that BDC wanted an out of the box software solution that was a mature and standardized product being used by a large number of other banks. The evidence establishes that Experian's response to BDC's RFI was meant to convey the impression to BDC that Experian's lending software met all of BDC's requirements when Experian's employees knew that it did not.

Events leading up to the Approval of Experian

[61] Following BDC's receipt of the three prospective vendors' responses to its RFI, each vendor conducted a demonstration of its software at BDC's office in Montreal in May 2008.

[62] When Experian's employees gave BDC a demonstration of its lending software in May 2008, BDC's employees believed the software they were shown was the RLS software that Experian wanted to sell to BDC. During the demonstration, Experian's employees did not distinguish between the software they were demonstrating and the lending software being used by a large number of US banks and a few international banks.

[63] Mr. Mehta admitted that he knew as of this demonstration in May 2008 that BDC expected to get a base product available for general release.

[64] Following the three demonstrations, Ms. Boutin testified that Experian was the "frontrunner" to supply BDC's software. However, the lending software that BDC was shown during the demonstration was not RLS 5.1 since it was neither deployed nor deployable at that time. Experian does not know what it actually showed to BDC's employees during the demonstration in May 2008.

[65] In June 2008, following the demonstrations, BDC documented its "Solution Recommendation" in which it concluded that Experian had "the best fit for BDC's needs" because its software had an 81% functional fit with BDC's requirements, with 1,200 installations and important features available "out of the box."[^20]

[66] Ms. Boutin testified that after this, she told Experian "that they were the number one out of the RFI and that we would have to do more detailed discussions during the summer."[^21]

[67] In July 2008, Experian and BDC held workshops in Montreal. Mr. Mehta testified that he attended the workshops. During his examination-in-chief, Mr. Mehta stated that he had discussed with certain BDC and LGS staff the development history of Experian's RLS software and how Experian planned to use the NAGE version of its RLS software to develop BDC's software as "an on-premise install." This was, of course, contrary to BDC's understanding that Experian was going to provide out of the box software that had already been developed. Mr. Mehta described the discussion as "pretty heated". He testified that "I was nervous because we were sitting in this room and … I was surrounded. I was the only Experian person in the room."[^22]

[68] Under cross-examination, he admitted that in July 2012 he testified during his examination for discovery that he did not know whether BDC had been told about the development history of RLS. He also admitted that although he assisted Experian's counsel in preparing the company's answers to undertakings, he never corrected his answer.

[69] Further, Experian's counsel provided the following undertaking during Mr. Mehta's examination for discovery:

Yes, we will let you know what BDC was told about the development history of RLS and to identify when and who told this to BDC.

Mr. Mehta provided the following answer to this undertaking:

Experian has no information regarding what BDC was told other than what has been produced.

[70] Mr. Mehta also admitted that the first time he had ever said that he provided BDC with the development history of RLS was during his examination-in-chief at trial. He had no explanation for the inconsistencies in his testimony. No other witnesses confirmed his evidence given during his examination-in-chief.

[71] Under the circumstances, and in particular because of the inconsistency between Mr. Mehta's discovery testimony, including his answer to the above noted undertaking, and his testimony at trial, I do not find Mr. Mehta's evidence on this issue credible or reliable. For this reason I attach no weight to it.

[72] In August 2008, Ms. Boutin and others from BDC visited Experian's office in Indiana. Experian's employees gave a slide presentation that described its RLS software as being "Used by over 1,200 financial institutions" and as an "End-to-end, Common Platform" and "Base Solution." According to Ms. Boutin, after this visit, BDC was "still very enthusiastic about RLS."

The Approval of Experian

[73] In October 2008, BDC's Board of Directors approved Experian as its chosen software supplier. The Board of Directors relied on a PowerPoint presentation that was based upon the representations that had been made by Experian's employees about its lending software. The presentation contained the following statements about Experian's lending software:[^23]

Baker Hill's RLS is Distinguished by its Customer Relationship Management and Financial Analysis Capabilities

❖ Our analysis shows a good functional fit (80%)

❖ Customer Relationship and sales Management capabilities "out of the box" including a Profitability Module

❖ Broadest footprint with 1,200 installations

❖ Workflow and rules engine are based on leading products

❖ Based on Microsoft .NET architecture – a good fit in BDC's current architecture

❖ Dynamic language translation supporting French, Chinese, Thai & Portuguese

[74] There is no evidence that Experian's employees said anything to BDC's employees from October 2008 until March 2009, when the Agreement was signed, to correct any of the representations that had been made to BDC's Board of Directors upon which they relied in approving Experian as BDC's software provider.

[75] Mr. Busch testified that he reviewed the October 2008 PowerPoint presentation to BDC's Board of Directors in April 2009 and incorporated the highlights of the presentation into an internal email memorandum congratulating his staff on Experian's Agreement with BDC. Mr. Busch's memorandum stated as follows:

BDC selected Experian's Baker Hill Relationship Lending Suite to serve as one of the key components of BDC's "Agility and Efficiency Program." … Our solution was selected because of our: strong functional fit with BDC's requirements; demonstrated business expertise; broad footprint with 1,200+ installations; workflow and rules engine based on lending products; Microsoft .net architecture -- a good fit in BDC's current architecture; dynamic language translation supporting French, Chinese, Thai & Portuguese.[^24]

[76] Under cross-examination, Mr. Busch agreed that he understood that the PowerPoint presentation accurately set out the reasons why BDC had entered into the Agreement with Experian. He testified as follows:

Q. … And so I take it that, even though this was dated in October 2008, you considered that - the thinking that was represented there to be - continued to be what you understood to be BDC's thinking right through to the time the contract was entered into; correct?

A. Well, I, I just took - I don't know what they were thinking but I took the bullet points of why they selected us and put them in here.

Q. And you didn't think anything had changed, obviously; otherwise, you would have pointed that out?

A. Right.

Q. … And I take it that you accepted what BDC said about their reasons for selecting RLS so that you could incorporate that into a communication that you were participating in to your colleagues at Experian?

A. I – yes. A general, high-level overview for internal people.[^25]

Events Following Experian's Approval by BDC

[77] In November 2008, Experian was developing a version of its RLS software for an international bank operating in the United Kingdom, the National Australia Group of Europe ("NAGE"). Mr. Daily testified that he decided that Experian would stop its development work on RLS 5.1 to devote its resources to developing new software for NAGE. His plan was to later restart Experian's development of RLS 5.1 for BDC using some of the work that had been done for NAGE.

[78] Mr. Daily did not advise BDC of his decision. He explained his decision as follows:

Q. When you paused the NAGE development … what was your expectation of the impact on BDC?

A. I didn't pause the NAGE development. I paused the base RLS 5.1.

Q. Yes.

A. I didn't anticipate that it would have an impact on BDC. Based on where BDC was at the time that I paused it, we were still in contract negotiations. I knew that we were going to have - when we got done with contract and based on where we were, I thought we were a ways out. I knew that after I got done - after we got done with the contract, we were going to start a fit/gap phase, which was going to take about two months. We would then go through and take a - and do our functional design phase, which could take anywhere from three months to four months. And then we would start tech design phase, where we would actually start doing the designs.

I knew that I wasn't going to need RLS 5.1 until we got at least a month into that tech design phase. So I didn't - so when I paused the RLS 5.1 because of NAGE, I was anticipating that I had a long time before I was going to need the base product for BDC.[^26]

[79] At the end of 2008, Experian delivered to NAGE the first iteration of the RLS lending software that was to be provided to it called RLS "code drop 0." Mr. Mehta sent an email message to Mr. Daily that was very critical of this software code. It stated, in part, as follows:

We are lucky to have a client with as much skin in the game as NAGE for our first endeavor as "prime."

If we tried to deliver "code drop 0" to any other client (i.e. BDC), you (and Craig) would have been on a plane shortly after I arrived to explain why we thought garbage was worth millions of dollars.

We didn't plan for this task, we didn't test, and we didn't resource appropriately.[^27]

[80] Mr. Mehta acknowledged that he never told anyone at BDC that he thought the software that was to be the foundation of BDC's software was "garbage." Ms. Boutin agreed that she had never been told this and that "garbage was not an option."

[81] In March 2009, Mr. Mehta expressed the following concerns in an email message to Mr. Daily about Experian's decision to devote resources from the development of BDC's software to the development of NAGE's software:

We are setting a bad precedent with this approach. Let's be very clear on where the approach of pulling resources from CAP to work on NAGE … is going to take us in the next year if it keeps up.

When we started NAGE we started with an incomplete CAP/Base, this is one of the reasons why the NAGE code line is where it is and one reason why we are riddled with bugs and issues. Granted there were a number of other problems, but this is one of the key issues; starting with a moving target. Although CAP is starting with NAGE and BDC is starting with CAP, there are significant changes that have to take place … to NAGE in order for it to be a stable starting point for BDC.

At this point we are still in release planning and the plan only indicates a small development need, so we will get by, but if we rob from Peter to pay Paul once the CAP … plan is built will be in the same situation with BDC that we are in now with NAGE.[^28]

[82] Mr. Mehta admitted that he did not tell BDC that the version of software that RLS 5.1 would be based upon was "riddled with bugs." He testified as follows:

Q. And we know from an e-mail you took us to or your counsel took us to earlier today that, about one month before the contract with BDC was signed, the NAGE code was still riddled with bugs. I think that was your words; right?

A. I did use the word "riddled" but I qualified what I meant there.

Q. But that's the words you used?

A. I did use the word "riddled", yes.

Q. All right. And that's about a month before BDC signed the contract?

A. That's correct.

Q. And at that point, internally, you think that the version of RLS that's going to be going as a base product to BDC eventually is going to be based on the NAGE version; right?

A. Yes.

Q. And you don't tell them that a month before they're signing the contract that that NAGE version is riddled with bugs; correct? You don't tell them that?

A. I didn't tell them that, no.

Q. And as far as you know, nobody else at Experian did either; right?

A. That's correct.[^29]

[83] In an email to Mr. Mehta on March 4, 2009, Steve Johnson of Experian, in referring to Experian's RLS software, stated as follows:

The bigger issue in my mind is ongoing management of base vs. client releases. While we have unique challenges with SCB and WBC, for NAGE, BDC and anyone else going forward we really need to come up with a strategy and stick to it or we are going to end up with four clients using four different products.[^30]

[84] Ms. Boutin testified that because BDC's employees thought that they were negotiating to acquire an existing base product in February and March 2009 they requested that Experian provide a user manual for the software. They were told by Experian's employees that they could not have the user manual until the Agreement was signed. As a result, BDC made it a term of the Agreement that a user manual was to be provided. What BDC's employees did not know was that the user manual did not exist at the time but was being drafted by Experian.

[85] In an internal email message to Mr. Mehta on March 27, 2009, the day the Agreement was signed, Deanna McLeroy, Experian's project manager on the BDC project, wrote about the "Base User Manual" as follows:

That said, BDC has always been looking to get these docs ASAP and we just said we couldn't share them until they had signed. They may not realize that by agreeing to have the commencement date further out they have delayed when they'll get this. In their minds, these already exist because we've sold them on a Base product.[^31]

The Agreement

[86] On March 27, 2009, BDC entered into the Agreement with Experian Canada. At the same time, Experian US unconditionally and irrevocably guaranteed Experian Canada's obligations under the Agreement (the "Guarantee").

[87] The Recitals to the Agreement state:

(A) BDC wishes to acquire certain software and related services from the Supplier (defined below).

(B) The Supplier is willing to provide such software and related services to BDC.

(C) In light of discussions concerning such supply, the Parties hereby agree that such supply of software and services will be undertaken in accordance with and subject to the terms and conditions of this Agreement.

[88] The Agreement contains the following definitions:

"Base Product" - means the object files which are incorporated in the Supplier's application or suite of applications known as "Relationship Lending Suite" and the components and elements thereof described in Schedule 1;

"Base Product Specifications" - means the functional, technical and non-technical specifications of the Base Product as set forth in the then current user documentation for the Base product that is delivered within five (5) Business Days following the Commencement date;

"Commencement Date" - means April 22, 2009;

"Release" - means any new version of the Base Product which is not an update; …

"Release One" - means the Software to be delivered under this agreement as described in the Specifications;

"Software" - means all software systems, tools, and computer programs delivered or made available to BDC by the Supplier under this agreement, which for the avoidance of doubt will include Developed Software and Base Product but which excludes Source Code Materials;

"Requirements" - means BDC's requirements for Release One set forth in Schedule 3;

[89] Schedule 3 to the Agreement is Experian's response to BDC's RFI.

[90] The Agreement also provides for the following:

• BDC was obligated to begin paying license fees for the Base Product when the Agreement was signed;

• Experian was obligated to deliver to BDC formal specifications of the work required to customize the Base Product to meet BDC's requirements by June 2009;

• Experian was obligated to deposit into escrow the source codes for the Base Product five days after BDC signed off on these formal specifications;

• Experian was obligated to provide written notice to BDC of the final amount of the cost of the implementation of the software and the timeline for achieving it by the end of the specification phase;

• It was contemplated that BDC would be able to "go live" with the Base Product and the necessary customizations to meet its requirements by October 2010.

[91] The Agreement also contains the following limitation of liability clauses:

20.1 Neither the Supplier or BDC shall, nor shall they purport to exclude or restrict liability for death or personal injury resulting from its negligence or that of its employees, servants or agents acting in the course of their employment, or resulting from fraud. Nothing in this agreement will seek to or operate to limit a party's liability in respect of liability that cannot as a matter of law be excluded.

20.4 Neither the supplier or BDC shall in any circumstances be liable to the other for the following losses:

20.4.1 lost profits, loss of business, loss of goodwill; or

20.4.2 any indirect or consequential loss,

in each case caused in any way by some act, omission, or misrepresentation (excluding fraudulent or negligent misrepresentation) committed in connection with this Agreement (whether arising from negligence, breach of contract or howsoever), even if such loss was reasonably foreseeable or specifically advised to that Party.

[92] Mr. Daily acknowledged that at the time the Agreement was signed, he and his team knew that the RLS 5.1 software referred to in the Agreement, was not completed and was not being worked on. They also knew that the NAGE software was in the process of being developed but it was riddled with bugs.

[93] An email message from Mr. Mehta to Mr. Daily on May 21, 2009 described the state of the software that Experian planned to provide to BDC as follows:

I am pretty frustrated with you. You should have been [sic] a better job resetting expectations. … You are months behind on getting me help, I'm holding up a house of cards over here, and I have to deal with this as well. We don't have a real base release yet you know that, and we only have so many people with a high enough IQ to deal with this stuff they are all going to have heart attacks at this rate. Tom is too integral to NAGE right now, and his wife just had surgery. Tom can probably provide some help next week; I just spoke with Don he thinks he can help some.

I'll work on this today but expectations have not been set properly with BDC.[^32]

[94] When asked about this email message, Mr. Mehta admitted that in May 2009 Experian was still developing the base product it was going to provide to BDC under the Agreement. He testified that "the base was still being developed. The 5.1 release was still in process."[^33]

[95] I agree with BDC's submissions regarding the Agreement set out at paras. 137 and 138 of its Written Closing Argument as follows:

137. The Agreement's reference to "Base Product" as RLS with the specific functionalities, was, in light of the factual matrix and the terms of the Agreement as a whole, clearly RLS 5.1 with the characteristics that Experian had described in its RFI response. No other interpretation makes sense of the discussions between the parties concerning the supply of software, the incorporation of the RFI response into the contract (which were based on RLS 5.1) and the structure of the Agreement, which provided for immediate license fees, prompt delivery of a "then current" user manual, and deposit in escrow of source code (all consistent only with an existing base product) and the purpose of the Agreement - to do customization on top of an existing base product which, as is, was supposed to already fit most of BDC's requirements.

138. Because RLS 5.1 did not exist, however, the Base Product in the Agreement did not exist at the time of the Agreement. Two consequences flow:

(a) Experian could not perform the Agreement; and

(b) The Agreement was effectively a continuing misrepresentation that Experian had the RLS 5.1 software it had described, which would form the base for what Experian would finally deliver to BDC.

Events Following the Agreement

[96] Ms. Boutin testified that after the Agreement was signed and BDC had paid license fees to Experian, she believed that BDC had the right to receive access to the base RLS software. She, therefore, requested that Experian provide BDC with a "vanilla" or "sandbox" version of the RLS software. She explained her request as follows:

Q. … So can you just tell us what exactly you asked for?

A. We asked for what we would call a demo version or a vanilla version or a sandbox, and that is what software vendors usually make available to their clients. It's a base version of the software that can be installed on premises and that the client can use, access.

And from our perspective well, we thought we were entitled to that because of the license fees we had paid and we were paying. But also from a project perspective, we needed that so that we could get started on data conversion and have a first look at the RLS database and also have our business experts start looking at the software in order to help with the change management efforts.

Q. So you told us you asked for a sandbox or a base version around the time of contract signing. Did you ever get one?

A. No. No.

Q. And other than around the time of contract signing, did you ever ask for a sandbox again?

A. I would ask for a sandbox every time I saw or talked to Mr. Daily. It was important to BDC.[^34]

[97] An internal Experian email message to Mr. Daily on July 21, 2009, refers to "Demo/Sandbox" as follows:

BDC is frustrated here because they are saying this request goes back to April. Unfortunately I don't believe timelines that are achievable for a sandbox are going to meet client desires. Alternatives are limited because the code they are looking for just does not exist at this time.[^35]

[98] Ms. Boutin testified that BDC never received a sandbox or base version of Experian's software.

[99] At the end of April 2009, Experian and BDC began the specification phase of the project called the "fit/gap" exercise. This involved determining where gaps existed between BDC's specific requirements and RLS's standard functionality. Mr. Marineau from BDC testified that he expected BDC would be provided with a vanilla version of the software that had been described in Experian's response to BDC's RFI to be used during the fit/gap exercise. This did not occur. According to Mr. Marineau, it was not possible to properly conduct the fit/gap analysis without having a base version of the software. He testified as follows:

Well, we were asking them, "Where is your system?" The idea again is really it's almost impossible to do a fit/gap if you don't see the system. You don't have anything to fit/gap against. Okay?

So it was more the description of what the system needs to support through all the tasks, which is very different from going to it's a requirement to understand how it works.

So we asked them many times, I think … we have discussed on a regular basis with Anne Boutin. But there was – it was a while later. Later, it's going to be coming. We had dates back then. I believe the target dates were pushed. But, yeah, we never saw the system.

So the idea was really to evaluate Baker Hill relationship lending suites, so Baker Hill RLS, and meeting BDC requirements.

So the BDC requirements are RFI requirements on which we had evaluated and selected the system amongst the three we had on our short list.

So not using the RFI requirement to do the exercise and also not seeing the system, it's almost impossible to do a fit/gap correctly.[^36]

[100] Mr. Busch agreed that the fit/gap analysis would involve comparing the base software with the client's requirements to identify the gaps between the two.

[101] I am satisfied on this evidence that Experian did not provide BDC with a base version of its software during the fit/gap exercise because it did not exist at the time. There was no base product that could be compared to BDC's requirements at this time.

[102] Mr. Daily essentially admitted this when he was cross-examined as follows:

Q. All right. No one at Experian had calculated a functional fit between any other RLS product and BDC, only with respect to RLS 5.1, as it might be developed in the future; correct?

A. Correct.[^37]

[103] Ms. Boutin testified that the fit/gap exercise was running into delays, in part because Experian was using a lot of its resources on the NAGE project. She kept pressing Mr. Daily for a vanilla or sandbox version of the software.

[104] On June 5, 2009 Ms. Boutin met with Mr. Daily in her office. She again asked for a sandbox version of the software. She described the meeting as follows:

… But since I had Mr. Daily in front of me, I used the opportunity to ask, again, for a sandbox or the demo, vanilla version.

And I was served a little bit of the same: No resources. Maybe later. And I insisted and I – my tone was probably not as friendly as it had been in the past, meaning I'm reaching the end of my rope on this topic. And, at that point, Mr. Daily told me that they did not have a base.

And it was a shock for me. I turned out being silent for a few seconds, a few minutes, which is not my typical self, being silent. And I told him - I said, "Now I understand. I understand a lot of the things that you've told us. And, you know, if you don't have a base, you can't provide documentation. You cannot provide a sandbox. I understand now."

But then I asked him - I said, "Did you think you could get by without BDC not finding out; that we would do this whole project without BDC finding out?"

And he said that it was in their plans to build a base at the fall of 2008, but given resourcing constraint, he had to put the resources on the NAGE project and forget about building a base. He made that decision in the fall of 2008.

So after that there wasn't much else to discuss I asked him to leave my office.[^38]

[105] Mr. Daily agreed with Ms. Boutin's description of the meeting.

[106] After her meeting with Mr. Daily, Ms. Boutin reported what Mr. Daily had told her about there not being a base to her supervisor, Chantal Belzile. Ms. Belzile testified about her discussion with Ms. Boutin as follows:

Q. Let's come to June 5, 2009. What, if anything, of significance happened that day?

A. … On that particular day, I walked into Anne Boutin's office. Anne shared with me that she just had a discussion … with Chris Daily and that Chris had told her that the base did not exist.

Q. Did she share other information about that meeting with Mr. Daily?

A. … This was a significant enough piece of information and … she seemed upset, understandably so. I told Anne, no, let's get to the bottom of this. Let's not overreact, and let's understand what's really going on.

Q. Why did you tell her not to overreact?

A. We, we had been on this project for several months. We didn't think one discussion statement being said, you know, without any - nothing written down or anything was cause enough to, you know, to stop such a project. I mean, so much happening.

From everything we had seen, everything we had been told by Baker Hill, this didn't make sense. You know, there's the 1200 installations that were in place. They would repeatedly talk about their installations at Westpac, at Siam. NAGE was being implemented. You know? And it was, it was not clear to me … that this was really the situation. Like, he was just panicking or something.

Q. And what, if any, direction did you give to Ms. Boutin?

A. To try to make this work.[^39]

Events after June 5, 2009 until the Termination of the Agreement

[107] After Ms. Boutin's meeting with Mr. Daily on June 5, 2009, Experian's employees indicated that they intended to use the custom software that had been designed for NAGE as the base that would be improved to meet BDC's requirements. Ms. Boutin explained this as follows:

Q. … so early August 2009, what was your understanding of what – in terms of software, what Experian would be offering BDC, if anything?

A. Well, they had told us that they were going to build and the version numbered 5.1 from the NAGE code and that would be the starting point for BDC.[^40]

[108] According to Ms. Boutin, BDC continued to work with Experian after she had learned that there was no base product because she had been assured by Experian's employees that the fit/gap exercise could be completed by October 31, 2009 and Experian could deliver software that met BDC's requirements. She testified as follows:

Q. Now, after these conversations that you have just told us about, how did you behave with Experian?

A. We kept on working with them, and I even kept asking for and I kept referring to what I was asking for as the sandbox, even though I knew they didn't have a base, but I kept asking for something that they could install.

We kept on working with them, because when - you know, we had seen RLS. Well, we thought we had seen RLS, and we loved what we saw. So we thought, well, okay, they don't have a base. Maybe … it's still a better starting point than if we were doing it from scratch.

So while the business impacts of the nonexistence of the base was being looked at by our sponsors, the project team, we continued to work with Experian, with Baker Hill.

Q. What were the discussions, if any, with Mr. Daily or anybody else at Experian about your understanding that there was no base at all?

A. Well, the fact that there was no base, we asked for the specifications for the fit/gap. What are we using? What are we working from to do the fit/gap?

And around that period, we found out that they were using various versions, some customer's version or some test versions that they were using. So we still continued to work and assess the fit/gap, the fit to get to specifications, because our objective was to get a complete picture of this situation …[^41]

[109] According to Ms. Boutin and Mr. Marineau, the fit/gap exercise did not go well because Experian did not have a base software system against which they could identify gaps and fits between BDC's requirements and Experian's base software that did not yet exist.

[110] As a result, there were many delays in completing the fit/gap exercise. The problem of there being no base product for BDC's software was highlighted in an internal memorandum from Larry Lanning, Experian's Senior Vice President and Executive Sponsor for its project with BDC dated July 27, 2009. Mr. Lanning wrote as follows:

Currently there are at least four versions of Base Software – one for WestPac, SCB, NAGE, and BDC (under development), and the clients using the software are in Australia, Thailand, Scotland, and Canada. Experian must determine how to provide Base software that is configurable and will meet a high percentage of the needs of clients in the selected markets. A firm plan to define and develop this configurable solution must be documented.[^42]

[111] Despite Experian's employees' assurances to Ms. Boutin, and others at BDC, that the fit/gap exercise would be completed by October 31, 2009, an internal memorandum regarding a "governance call" with BDC from Experian's senior executive, Gary Kearns, to Mr. Daily and others dated September 3, 2009 recorded the following:

Chris and I attended the call with the BDC governance team today …

We went through the usual dates and confirmed we were on schedule. Oct. 31 for base code; Oct. 1 for documentation. They noted concern that they're not sure what equipment they need to have to enable them to get the base code up and running. My personal concern is do they really understand what they're getting and this is not the finished solution for them. …

What makes this really interesting is that they won't have anything approaching the finished product. So what Chris is working on is to give them the base code stripped out from one of our previous installations so that they can play with it. The problem is that it may not resemble very closely their solution. Chris needs to brief us in more detail here on his plan and how we can get them comfortable that their business case is still intact or at least the minimum threshold has been met.[^43]

[112] According to Ms. Métivier, by August 2009, she began to doubt that Experian could deliver the software it had promised. She testified as follows:

Q. So what happened in early August?

A. So we have a meeting, a face-to-face meeting in August with Mr. Kearns, who was the senior leader in this project. And participating to that meeting is Baker Hill and also part of my team. So Anne would have been there - Anne was there and so was I.

During that meeting we outlined to Baker Hill the elements that we were not satisfied on, basically. And the first item was the base software. So you missed the deadline. Here is what we're proposing to you to remedy. Can you actually give us an updated software or the software by October 1st?

So this is the August meeting. Gary Kearns, in that meeting, says that he's going to take this into consideration, or comes out of the meeting saying "I'll be back to you. I'll consult my team and see if we can actually meet these requirements." So that's the first meeting.

I have to tell you, though, that, at that meeting, I start doubting that Baker Hill has the capability, actually, to be able to deliver on what they are saying.[^44]

[113] By mid-September Ms. Métivier became increasingly concerned that Experian could not deliver the software it had promised BDC. She described a further meeting with Mr. Kearns as follows:

Q. So what was the next step that you were personally involved in?

A. The next step is September 15, and here my memory is not accurate. I don't know if it is a face-to-face meeting or if it is a call. So I can't recall.

But this is the meeting where Gary Kearns actually comes back to us and basically says that he cannot meet the deadline. And that meeting was not a pretty meeting, in the sense that I think that's where I understood what Anne had tried to tell me earlier, that the software really didn't exist.

In my mind, I thought, "Well they have implemented a software in three other banks, so the software must exist." But the September 15 is really when I come to the conclusion that Anne is right, and the software doesn't exist. They won't be able to deliver on it.[^45]

[114] As a result of this meeting, Ms. Métivier instructed Ms. Boutin to conduct more due diligence of Experian's software. This included the engagement of Accenture, a computer software consultant, in October 2009, to do a "high spot review" of Experian's software to determine if the project could be salvaged. She also directed Ms. Boutin to visit NAGE in Scotland to review its software that had been provided by Experian.

[115] Ms. Boutin testified that she and Ms. Belzile attended meetings at Experian's office in Indiana in early October 2009 with representatives of Accenture to conduct the high spot review. According to Ms. Belzile, Mr. Daily made the following statements during the meetings:

• No customers were using the RLS base product that had been described to BDC by Experian in 2008. In fact, this software was to be designed later and its release was being done on a client-by-client basis.

• Experian had assumed that shortly after it signed the Agreement with BDC it could install the NAGE software at BDC but it turned out for intellectual property reasons, it could not.

• BDC was never told that there was a difference between the RLS solution that Experian was going to provide to it and Experian's domestic ASP product that was installed with 1,200 customers.[^46]

[116] In late October 2009, Ms. Boutin and Ms. Belzile visited NAGE in Scotland. Ms. Belzile testified that after reviewing NAGE's software she concluded that it was not even as good as the software BDC was currently using. She testified as follows:

… And this was, to us … the conclusion or the last piece of the due diligence. What we were able to observe and the impression we got confirmed the feeling we had coming out of Baker Hill, the software just wasn't mature. If anything, it was providing less than our current software that we were running at the time, and the processes to manage - Baker Hill to manage an installation just weren't mature. The stability wasn't there in the system. So it just concluded that we could not continue with this.[^47]

[117] Ms. Belzile testified that she and Ms. Boutin concluded, on their way back to Montreal from Scotland, that Experian's employees had lied to them about the software. She testified as follows:

Well, on the way back … Anne and I had a fairly long layover in London. And I remember sitting down in London Heathrow Airport and asking her how on earth did we get here. And so we talked about the fact that we started by believing that what we were getting was a solution that was in place at 1200 clients and how, over time, how that started to fade away. And we ended up realizing that what we were going to get was something that was just being built and was not even complete. And the conclusion that we reached, we looked at each other and said, well, we were lied to.[^48]

[118] According to Ms. Boutin, after they returned from NAGE, they reviewed Experian's responses to BDC's RFI that had been provided in May 2008. They recalculated the "fit" with BDC's requirements using the information they had in November 2009. They concluded that rather than the 81% functional fit BDC had calculated based upon Experian's responses to the RFI, the functional fit was actually only 46% based upon what they had since learned about the software. Ms. Boutin testified that if they had known this in June 2008, BDC would not have moved forward with Experian.

[119] On November 10, 2009, Ms. Boutin wrote to Mr. Daily and demanded that Experian provide BDC with the cost of and a timetable for implementing the software. Experian responded on November 13, 2009, providing contractual timelines and prices for different scenarios. Experian indicated that it would charge $13.09 million and take an additional 18 months to deliver software that would meet all of BDC's requirements. Alternatively, Experian offered to deliver what it described as BDC's "high priority requirements" for a price of $11.2 million in an additional 16 months. This was Experian's "Recommended Option."

[120] On November 19, 2009, BDC terminated the Agreement. Mr. Paul Buron, BDC's Executive Vice President and Chief Financial Officer, stated as follows in BDC's termination letter:

Simply put, Experian misled BDC with respect to the key fact that led BDC to contract with Experian to license purportedly existing Experian software, which in fact did not exist. Experian has now admitted to BDC that at the time of contracting Experian did not have Base software, but appears to have hoped to build it without BDC discovering the truth. As was known by Experian, this sell it now and try to build it later approach was incongruent with BDC's needs. The excessive delays that have been encountered in this project, and that would be encountered if it continued, and Experian's recent but long delayed estimate of "Development Charges" of in excess of $13 million, almost about three times what Experian led BDC to believe would be required for this project, flow directly from Experian's fundamental misrepresentation.[^49]

Events Following the Termination of the Agreement

[121] After BDC terminated its Agreement with Experian it reassessed the project and explored other options. It came up with a "Plan B" that initially involved developing in-house at BDC a hybrid lending system made up of components licensed from third party suppliers and other components built specifically for BDC.

[122] It took BDC about one year to prepare a detailed Request for Proposal for this plan. BDC then engaged an outside IT consultant to write detailed specifications for the custom software BDC required. Most of the requirements BDC had requested from Experian in its RFI were maintained, although some functionality was removed to reduce costs and to expedite the process so that the new software could be implemented by 2014.

[123] According to Ms. Belzile, who took over responsibility for the project in 2012, BDC moved away from the development of a hybrid system to custom software that used sophisticated technology called Mendix. BDC coded its lending application within ten months, tested it and went live with its new software, CLICS, in June 2014.

[124] Pierre Dubreuil testified that he is in charge of all of BDC's commercial lending operations. Commercial lending represents about 90% of BDC's operations in terms of revenue. He explained certain process changes that BDC implemented in conjunction with its new CLICS software.

[125] According to Mr. Dubreuil, BDC implemented four packages of process changes in 2013. He testified that these process changes were tied to when CLICS was expected to go live and could not have been implemented any earlier. He was cross-examined on whether the process changes could have been implemented earlier and he explained why they could not have been. He testified as follows:

Q. Could you not have released this package six months earlier?

A. I explained, in theory, it could have been, but, no, because of risk, risk effect, I guess, because as a lender, we have a lot of risks, credit risk. We were changing processes before getting the actual platform.

So, for example, we went from two signatures to one signature, the reason being why would we do this is that the documents would have been standardized. So if we changed it from 2 to 1 and not deployed the platform, this would have created some operational risk and that kind of thing. So we would not have deployed that without the intent of deploying the platform.

We were ready to take more risk for a limited period of time.

Q. You are taking more risk for a limited period of time. And then when the software came in, you hoped to mitigate that risk?

A. Yes, of course. Because we moved to standardized documents.[^50]

[126] Eric Carrière testified about how much more efficient BDC's new CLICS software is in comparison to the previous CREM Manager system. He explained that CLICS is more efficient because of the following improvements:

• It involves less use of paper;

• It saves 15-20% of time because the rekeying of information is reduced;

• Small loans can be processed much faster; and

• Disbursements of loans is quicker.[^51]

[127] Mr. Carrière testified about the increased efficiency of CLICS as follows:

To me, the efficiency has greatly allowed me to increase my work productivity. Just by working from home, I save an hour and a half a day … I would estimate that I can do 10 to 15 per cent more loans than I would have done before CLICS deployment.[^52]

[128] I accept BDC's counsel's description of the financial benefits that BDC achieved from the implementation of CLICS and the related process changes that Mr. Dubreuil described set out at paras. 179 – 183 of BDC's Written Closing Argument as follows:

179. In October 2008 when BDC first sought board of directors' approval for the lending aspect of the A&E project, it justified the estimated costs of new lending software by a business case that anticipated financial benefits of increased productivity and better efficiency. The financial benefits were measured comparing the time it took BDC to conduct activities under both its current systems and what was anticipated once it optimized its processes and technology.

As set out in the presentation to BDC's board of directors about the anticipated benefits of the A&E program, "Extra Time freed up by A&E is then monetized", and time freed up was translated into person year equivalents or "PYEs" which when multiplied by the amount of BDC's average salaries yielded an anticipated dollar amount saving.

180. BDC updated the business case in 2010 and 2012, using the same methodology. Mr. Lucarelli, in his role as a Vice President in BDC's finance department, was involved in these business cases. Mr. Lucarelli's evidence was credible and not challenged.

181. In 2013, Mr. Lucarelli was asked to review the business case, and he was involved in changing the methodology to calculate the anticipated benefits knowing that BDC would need to measure the actual benefits once the CLICS software was implemented. Accordingly, the following three productivity ratios, which BDC already used internally to measure productivity, were selected for use:

(a) the number of loan acceptances per account manager ("AMs");

(b) the number of clients per portfolio management support employee ("PMSEs");

(c) the number of loan acceptances per loan origination support employee ("LOSEs").

182. Using these productivity ratios, savings could be estimated by taking a reference or base year before implementing any changes, against which the performance in a future year would be measured for each of the AMs, PMSEs and LOSEs. To the extent that the productivity ratios improved as against the base year because of increased efficiency, BDC could calculate the number of people year equivalents ("PYEs") that were saved. The average cost of each type of employee could then be multiplied against the PYEs saved, to calculate a financial benefit.

183. Once CLICS was implemented, BDC used this productivity methodology to actually measure the benefits that were received by BDC as of October 31, 2015, benefits that were and are expected to continue. BDC had sought out lending software in order to gain efficiency benefits and its own measurements, using established productivity ratios, showed that when the software was finally implemented, those benefits were realized.

Expert Evidence Regarding Liability

[129] Professor Gail Murphy, Ph.D., testified on behalf of BDC. She is a professor of computer science, specializing in software engineering, and the Associate Dean for Graduate Studies and Research, in the Faculty of Science at the University of British Columbia. Professor Murphy was qualified as an expert witness with respect to software engineering.

[130] Professor Murphy testified that she was asked to answer the following question:

A. …, in 2008 and 2009, whether Experian had a base solution providing relationship lending functionality.

Q. And did you come up with an answer?

A. I did. Based on an analysis and review, I found that there was a lack of identifiable and testable core assets, meaning common software, between the software products. I found that there was a lack of a well-defined process for managing those common assets across the products and even involving them in time. And I found out that there was a lack of assets that form the majority of any of the products.

So, as a result, my opinion is that Experian did not have a base solution product for relationship lending in 2008 and 2009.[^53]

[131] Professor Murphy also testified that in her opinion even at the end of BDC's and Experian's relationship, in November 2009, RLS 5.1 was not a base solution.

[132] Professor Murphy's analysis, as summarized by BDC's counsel, is attached as Appendix "A" to these Reasons.

[133] Experian challenged Professor Murphy's analysis as being too academic and criticized the computer program she developed to analyze Experian's software because it had not been published or reviewed by her peers or any other experts. Experian also challenged her file name analysis on the ground that it underrepresents similarities between file names in Experian's software.

[134] Experian called Michael Jackman, an electrical engineer with extensive experience in the lending and risk management software industry, as an expert witness to critique Professor Murphy's opinion. BDC objected to his qualifications to give expert evidence. Following a voir dire concerning his qualifications, I qualified him as an expert witness to give opinion evidence only with respect to "the marketing, development, sales, and implementation of application software relating to the lending industries." I did not qualify him to give opinion evidence on "source codes or anything technical."

[135] Mr. Jackman testified that in his opinion Professor Murphy's analysis would be of little relevance to a purchasing decision made by a financial institution with respect to lending software. He explained that financial institutions typically do not undertake an analysis such as Professor Murphy did and software vendors do not typically provide to prospective customers the kind of information she used in her analysis.

[136] Professor Murphy's conclusion that Experian did not have a base solution in 2008 or 2009 was not challenged by Mr. Jackman or any other Experian witness. Further, Professor Murphy's conclusion and her overall methodology was not effectively challenged during her cross-examination. I found Professor Murphy to be a reliable, impressive and candid expert witness. Her analysis seems reasonable and her conclusion was not challenged by any other evidence.

[137] Under these circumstances, I accept Professor Murphy's evidence that Experian did not have a base solution product for relationship lending in 2008 or 2009.

Legal Analysis

Did Experian make fraudulent misrepresentations regarding its software or its capabilities to BDC and, if so, did BDC rely on the misrepresentations in a manner that caused it damage?

[138] The first issue that I must determine is whether Experian made fraudulent misrepresentations regarding its software or its capabilities to BDC.

[139] There is no dispute that the elements of the tort of fraudulent misrepresentation are as follows:

1. the defendant made a false representation of fact;

2. knowing that it was false or recklessly without belief in its truth;

3. with the intention that it would be acted upon by the plaintiff;

4. which induced the plaintiff to act; and

5. the plaintiff suffered damages as a result.

First Element

[140] I agree with Experian's submission that the false representation required for the first element of fraudulent misrepresentation must be the representation of an existing fact not a forecast, estimate or an opinion. Although a forecast, estimate or opinion about a future event cannot constitute a false representation of fact, it is a false representation of fact to state that something is currently true or existing when it is not. The Supreme Court of Canada made this clear in Queen v. Cognos[^54] in which case Iacobucci J. stated as follows:

Obviously, some aspects of the misrepresentations made to the appellant about the employment opportunity were, by their very nature, matters in futuro. Statements about the appellant's involvement with the respondent and his responsibilities should he be offered a position are representations that relate to future conduct and events. There are authorities supporting the view that only representations of existing facts, and not those relating to future occurrences, can give rise to actionable negligence …

However, assuming without deciding that this view of the law is correct, the representations most relevant to the appellant's action are not those relating to his future involvement and responsibilities with Cognos, but those relating to the very existence of the job for which he had applied. That is a matter of existing fact. It was implicitly represented that the job applied for did in fact, at the time of the interview, exist in the manner described by Mr. Johnston. As found by the trial judge, however, such was not the case. The employment opportunity described to the appellant was not, at the time of the interview, a fait accompli for the respondent. Clearly, this misrepresentation relates to facts presumed to have existed at the time of interview …

[141] In my view, Experian's employees represented to BDC's employees that the software described in Experian's response to BDC's RFI (RSL 5.1) currently existed when it did not. This was a false representation of an existing fact. This false representation of fact continued until June 5, 2009, when Mr. Daily finally told Ms. Boutin that the base product that had been described in Experian's response to the RFI did not exist.

[142] I am satisfied that the first element of fraudulent misrepresentation has, therefore, been established.

Second Element

[143] The second element of fraudulent misrepresentation requires that the misrepresentation is made with knowledge that the statement is false or recklessly without belief in its truth. The evidence establishes that when Experian responded to BDC's RFI, Mr. Daily was aware that RLS 5.1 did not currently exist and was only under development. I am satisfied that he was aware that Experian's representations to BDC about its base software were not true. At the very least, Mr. Daily was reckless in allowing the representations concerning Experian's base software to be made to BDC.

[144] McLauchlin J. (as she then was) described recklessness as follows in Noble v. Fuller, Ellis Realty Ltd.:[^55]

The essence of recklessness is not a premeditated intention to deceive, but a wanton disregard as to whether one deceives or not. When a professional salesperson chooses to give answers to serious questions from potential purchasers without ascertaining whether or not they are true, recklessness and the tort of deceit are established.

[145] I am satisfied that the second element of fraudulent misrepresentation has, therefore, been established.

Third Element

[146] The third element of fraudulent misrepresentation requires that the false statement be made with the intention that it will be acted upon. I have already found that Experian's response to BDC's RFI was meant to convey the impression to BDC that Experian's lending software met all of BDC's requirements when it did not. I am satisfied that Experian's employees made the false statements about its software with the intention that BDC's employees would rely upon them and decide to acquire Experian's software as a result.

[147] I am satisfied that the third element of fraudulent misrepresentation has, therefore, been established.

Fourth Element

[148] The fourth element of fraudulent misrepresentation requires that the false statement induced the plaintiff to act. Ms. Boutin's evidence, and the evidence of many of the other BDC witnesses, make it clear that BDC was induced to deal and contract with Experian because of the false statements about Experian's software. According to Mr. Eatock, Experian would not have even made it to BDC's medium vendor list if the false statements about its software had not been made.

[149] I am satisfied that the fourth element of fraudulent misrepresentation has, therefore, been established.

Fifth Element

[150] The final element of fraudulent misrepresentation requires that the plaintiff suffered damages as a result of the false statement. I accept BDC's witnesses' evidence about the delay it experienced in implementing new more efficient lending software because of the 18 months it wasted dealing with Experian. If Experian's employees had been truthful about the software Experian could deliver, I find that BDC would not have dealt with Experian and would not have entered into the Agreement.

[151] I am, therefore, satisfied that the fifth element of fraudulent misrepresentation has been established.

Experian's Submissions

[152] Mr. Wall, on behalf of Experian, made the following closing written submissions in support of Experian's position that none of its employees made any misrepresentations to BDC:

• In order to succeed in its claim for fraud, BDC must prove that Experian made a misrepresentation of fact – not an estimate, a prediction, a promise or mere puffery.

In my view, although certain of Experian's representations about its software were estimates many significant representations were clearly representations of existing facts, such as the fact that RLS 5.1 currently existed with the characteristics described in Experian's response to BDC's RFI.

• If Experian believed the statements at issue, there is no fraud, regardless of how reasonable, negligent or inaccurate the belief in the truth of the statements may have been.

I do not accept this submission because I am satisfied based upon their admissions at trial and the documentary record that Mr. Daily and Mr. Mehta were well aware that many of Experian's statements to BDC about the current state of RLS 5.1 were not true. There is no other reasonable inference to draw on all of the evidence.

• Experian answered BDC's RFI truthfully by providing BDC and its external consultant, LGS, with information about … the version of RLS it was seeking to install at BDC.

The problem with this submission is that it ignores the fact that Experian did not tell BDC it was answering the RFI on the basis of what "it was seeking to install". Instead, Experian represented to BDC that the software it described and planned to install at BDC currently existed when it did not.

• Experian had an RLS base product at all relevant times.

This statement ignores the fact that it did not have and never had a base product for RLS 5.1. This was the software that Experian described as existing in its response to BDC's RFI. According to Mr. Mehta, the base product that Experian did have for NAGE was "garbage," "riddled with bugs and issues," and could not be used "as a stable starting point for BDC." Further, I accept Professor Murphy's opinion that a base product for RLS 5.1 never existed.

• Experian had no knowledge of any expectation by BDC that the RFI responses must be based on a version of a vendor's software generally available at the time of the response.

I do not accept this submission primarily because in response to many questions in BDC's RFI, Experian provided a score of 5 in respect of RLS 5.1. A score of 5 meant that Experian represented to BDC that the particular "feature" of RLS 5.1 "is standard functionality of our product." In my view, there is no other way to interpret this answer than that the version of the software described in the RFI existed at the time of the response. The response was not true since the product did not exist at that time.

• Many of the problems that occurred during the fit/gap process were because of BDC's additional requirements for the software which Mr. Wall describes as BDC's "scope creep".

This may be true but it is not an answer to the other problems that occurred because of Experian's misrepresentations about its software.

• There was no positive obligation on Experian to decry RLS as an inferior product, or to ensure that its self-promotion would not be interpreted in a manner that Experian did not intend.

I agree that Experian was not obligated to "decry" its product but it was obligated to describe it truthfully, which I have found it did not.

[153] During his oral submissions, Mr. Wall stated as follows:

My friend referred to the Pommer case, the US one about the patent, where it was fraud if you said that a patent existed even if you later got the patent.

And this is not that case. This is where Baker Hill/Experian had an honest belief that the software would exist in the future and answered the RFI on the basis of that software. But that software would be the one that was deployed. In other words, it was describing a circumstance that it expected to occur in the future.

[154] I do not agree with Mr. Wall's submission that the circumstances of this case differ from the circumstances in the decision Mr. Wall referred to of the United States Court of Appeals for the Seventh Circuit in Pommer v. Medtest Corp.[^56] In Pommer, Mr. West, one of the principals of Medtest, told the Pommers that the company had a patent on a process that was going to be sold imminently to a large pharmaceutical company. On the strength of this representation, the Pommers purchased shares in Medtest. Medtest did not have a patent at the time although Mr. West expected that it would obtain the patent in the future. In fact, Medtest did obtain the patent two years later. In the court's decision, Easterbrook J. stated as follows:

West told the Pommers that Medtest had a patent, doubtless recognizing that in selling stock as in other endeavors a bird in the hand is worth two in the bush. Counsel's belief that the process is patentable is a fair distance from a patent. … just as a statement true when made does not become fraudulent because things unexpectedly go wrong, so a statement materially false when made does not become acceptable because it happens to come true.

[155] In my view, the US Appeals Court's decision is applicable to this case. I agree with Justice Easterbrook's analysis. Experian's employees' belief that the software they described when they responded to BDC's RFI would eventually be developed "is a fair distance" from their representations that the software existed at the time Experian responded to the RFI.

[156] Despite Mr. Wall's able argument, I have concluded that Mr. Daily, Mr. Mehta, Mr. Busch and other Experian employees were well aware that the RLS 5.1 software they had told BDC existed did not exist. The only rational inference that can be drawn from an examination of all of the evidence is that these Experian employees knew that the representations they made to BDC about the RLS 5.1 software were not true. I am satisfied that Experian's employees did not make their representations to BDC about Experian's software truthfully. At the very least, they were reckless in doing so.

[157] Finally, there can be no dispute that Experian US is responsible for the actions of its employees. Fraud will be attributed to a corporation where it is committed by the corporation's employees acting within the scope of their authority. There is no dispute that all of the individuals who made false statements to BDC were Experian US's employees acting within the scope of their authority.

[158] For all of these reasons, I have concluded that Experian US made fraudulent misrepresentations regarding its software and its capabilities to BDC, and BDC relied on those representations in a manner that caused it damage.

Did Experian breach the Agreement with BDC?

[159] There is no dispute that I must interpret the Agreement in the light of the factual matrix which includes all of the events that occurred between Experian's and BDC's employees leading up to the signing of the Agreement. The preamble to the Agreement makes this clear when, in referring to Experian's supply of software to BDC, it states as follows:

In light of discussions concerning such supply, the Parties hereby agree that such supply of software and services will be undertaken in accordance with and subject to the terms and conditions of this Agreement. (emphasis added)

[160] The Agreement contains the following terms that relate to Experian's base product:

• "Base Product" is defined to include Experian's "application or suite of applications known as 'Relationship Lending Suite;'"

• "Software" is defined to include "Developed Software and Base Product;"

• Experian's response to BDC's RFI is incorporated into the Agreement as Schedule 3;

• Experian is required to deliver to BDC, no later than April 27, 2009, the functional, technical and non-technical specifications of the "Base Product" as set forth in the "then current" user documentation including the user manual;

• BDC is required to start paying license fees for Experian's "Base Product" immediately;

• Experian is required to provide BDC with formal specifications for Experian's development work to customize its Base Product to meet BDC's requirements by June 2009;

• Experian is required to deposit into escrow the source codes for the Base Product within five days of the signing of the Agreement;

• The Agreement contemplates that BDC would "go live" with the customized Base Product by October 2010.

[161] Based upon the evidence of Mr. Daily and Mr. Mehta, which is part of the factual matrix, references in the Agreement to Experian's Base Product are references to RLS 5.1 with the characteristics set out in Experian's response to BDC's RFI. The fact that Experian's response to BDC's RFI is incorporated into the Agreement further supports this interpretation.

[162] The references to the Base Product contained in the Agreement set out above clearly suggest that a Base Product currently existed when the Agreement was entered into. The requirements that BDC immediately start paying license fees for the Base Product and that Experian deliver a "then current" user manual and deposit into escrow source codes for the Base Product do not make commercial sense if the Base Product did not exist when the Agreement was signed.

[163] The evidence establishes that RLS 5.1 did not exist when the Agreement was entered into. As a result, Experian could not perform the Agreement insofar as it related to Experian's Base Product. Further, the Agreement continued Experian's fraudulent misrepresentations by incorporating Experian's response to BDC's RFI. The references to Experian's Base Product in the Agreement presupposes that it exists when it does not. I find that this is a further fraudulent misrepresentation for the same reason that Experian's response to BDC's RFI is a fraudulent misrepresentation.

[164] For these reasons, I have concluded that Experian Canada breached the Agreement with BDC. To the extent that Experian Canada is liable to BDC for its breach of the Agreement, Experian US is also liable because of its unconditional and irrevocable Guarantee of the obligations of Experian Canada under the Agreement. Experian did not argue at trial that Experian US was not liable for Experian Canada's breach of the Agreement.

What is the effect of the limitation of liability clauses in the Agreement?

[165] The Agreement contains the following clauses that limit each party's liability:

20.1 Neither the Supplier or BDC shall, nor shall they purport to, exclude or restrict liability for death or personal injury resulting from its negligence or that of its employees, servants or agents acting in the course of their employment, or resulting from fraud. Nothing in this Agreement will seek to or operate to limit a Party's liability in respect of liability that cannot as a matter of law be excluded. (emphasis added)

20.2 Except in the case of liability pursuant to

20.2.1 Clause 12.4 (Intellectual Property Right Infringement); or

20.2.2 a breach by Supplier of the obligations of confidentiality in Clause 14,

in respect of which the Supplier's liability is unlimited, and subject to Clause 20.1, the total aggregate liability of the Supplier under this Agreement in respect of each event or series of connected events relating to any of the Deliverables, Document Deliverables, or Services, regardless of the form of action whether in contract, tort or otherwise:

20.2.3 will not exceed 100% of the Development Charges payable under this Agreement in the case of any event of breach occurring before the first day of the Support Period, and

20.2.4 will not exceed 100% of the Support Charges payable in the Support Year in which the claim accrues in the case of any event of breach occurring on or after the first day of the Support Period.

20.4 Neither the Supplier or BDC shall in any circumstances be liable to the other for the following losses:

20.4.1 lost profits, loss of business, loss of goodwill; or

20.4.2 and indirect or consequential loss,

in each case caused in any way by some act, omission, or misrepresentation (excluding any fraudulent or negligent misrepresentation) committed in connection with this agreement (whether arising from negligence, breach of contract or howsoever), even if such loss was reasonably foreseeable or specifically advised to that Party. (emphasis added)

[166] Experian relies upon Clause 20.2 in support of its position that its liability to BDC is limited. However, Clause 20.2 states that it is "subject to Clause 20.1" that specifies that a party's liability for fraud cannot be limited.

[167] Further, Clause 20.4 that restricts a party's liability for lost profits and consequential loss excludes losses arising from fraudulent misrepresentation.

[168] BDC has established that Experian made fraudulent misrepresentations in connection with its Agreement to provide lending software to BDC. Experian's liability flowing from its fraudulent misrepresentations cannot be restricted by these clauses because they specifically exclude any restriction of a party's liability for fraud and fraudulent misrepresentation.

[169] Experian submits that public policy favours the strict enforcement of exclusion clauses in contracts where a party seeks to escape the effect of the exclusion clause. However, this principle does not apply in this case where the clear wording of the Agreement does not restrict liability where either fraud or fraudulent misrepresentation exists.

[170] During oral argument, Mr. Wall conceded that the limitation of liability clauses do not apply to BDC's alleged tort of fraudulent misrepresentation.

[171] For these reasons I have concluded that the limitation of liability clauses in the Agreement do not apply to BDC's claims based upon Experian's fraudulent misrepresentations and breach of contract.

If Experian is found to be liable for fraudulent misrepresentation, breach of contract, or both, what is the proper measure of damages?

[172] BDC seeks damages of $57 million plus punitive damages of $500,000. Howard N. Rosen gave expert opinion evidence about the damages BDC has suffered as a result of Experian's fraudulent misrepresentations and breach of contract.

[173] Mr. Rosen was qualified as an expert witness in the quantification of economic damages. He provided two different approaches for the calculation of BDC's damages. The first is based upon Experian's breach of the Agreement. Mr. Rosen calls these damages "Experian's Impugned Conduct." The second approach is based upon Experian's fraudulent misrepresentations. Mr. Rosen calls these damages "Dealing with Experian." Mr. Rosen described the rationale and methodology of these two approaches to the calculation of BDC's damages in his expert report dated November 20, 2015 as follows:[^57]

2.1 We understand that commencing in 2006, BDC began a process to implement new business systems integrated with new technologies under their Agility & Efficiency project (the "A&E Project") in order to improve the efficiency of their lending services and yield economic benefits including human resources costs savings. BDC management determined that the costs of the A&E Project would be worth incurring because the longer term economic benefits would be much greater than those costs.

2.2 We further understand that Experian caused a delay to BDC in realizing the economic benefits from the A&E Project. Since the economic benefits were to be realized over a long-term period, the delay in realizing these benefits has created permanent loss to BDC, as it will not be able to recover these benefits in the future.

2.3 In addition to the loss of economic benefits from the new business systems and technologies we understand that the BDC also incurred incremental costs to hire third parties other than Experian to complete the portion of the A&E Project that Experian was to have implemented under the Agreement but did not for the reasons alleged by BDC.

2.4 We have calculated the damages to BDC allegedly caused by Experian as the reduction in economic benefits realized and increased costs incurred in the implementation of new software and business processes relating to BDC's lending services allegedly caused by Experian's alleged failure to perform its obligations under the Agreement with BDC and certain statements and conduct of Experian. ("Experian's Impugned Conduct").

2.6 We have also prepared calculations of the damages to BDC as a result of time and costs BDC spent dealing with Experian. For the purposes of this calculation, we have been asked to assume that BDC was wrongly induced to deal with Experian due to certain pre-contract statements and conduct by Experian, and that if that had not occurred BDC would not have dealt with Experian past the initial stage of the vendor evaluation process, and would not have spent approximately 18 months of time working on the software solution proposed by Experian or negotiating and executing the Agreement. Rather, BDC would have commenced working much sooner on the build/buy solution that it eventually adopted. As a result of the delay caused by dealing with Experian, BDC completed the A&E Project and began to realize the benefits therefrom 18 months later than it would have absent this delay. As noted above, the economic benefits to BDC are to be realized over the long-term, thus the 18 month delay caused a permanent loss to BDC since it will not recover these benefits in the future. In addition to the loss of benefits over the 18 month delay period, we have included the incremental costs BDC incurred in dealing with Experian which are costs it would not have incurred absent Experian's involvement in BDC's A&E Project.

[174] Under Mr. Rosen's breach of contract analysis he calculated the difference between the total costs that BDC actually incurred in implementing CLICS ($37,245,764) and the cost of Experian's revised proposal in November 2009 ($21,658,359) to be $15,587,405 He also calculated the loss of economic benefits for the 25 months between when BDC should have begun to achieve benefits from the software Experian was to provide under the Agreement and when BDC started to achieve economic benefits from CLICS to be $70,167,800. When pre-judgment interest is added to these two amounts BDC's total loss from Experian's breach of contract is $87,006,200 according to Mr. Rosen.

[175] Under Mr. Rosen's fraudulent misrepresentation analysis, he calculated the incremental costs incurred by BDC from its dealings with Experian to be $3,307,037. This amount is made up of $1,111,496 that BDC paid to Experian in development charges and license fees; $274,944 paid to consultants, including Accenture, to retire CREM; $1,321,686 paid to Accenture for integration and data conversion to the RLS system; $230,887 in travel and living expenses billed by Experian; $230,228 paid to Accenture to do the high spot review; and $137,796 in legal fees.

[176] Mr. Rosen used the same methodology to calculate BDC's loss of economic benefits. However, he used a delay period of 18 months—the period of time that he assumed BDC had wasted dealing with Experian—rather than 25 months. He calculated this loss to be $49,368,500. When pre-judgment interest is added to these two amounts BDC's total loss from Experian's fraudulent misrepresentations is $53,650,200 according to Mr. Rosen.

[177] Because the fundamental basis of BDC's claim against Experian is for the fraudulent misrepresentations its employees made to BDC about its lending software, I prefer Mr. Rosen's damage calculation based upon Experian's fraudulent misrepresentations. In my view, it is a more accurate measure of BDC's damages. I agree with Experian's counsel's closing submission that, "[t]he proper measure of damages in tort is the amount of money required to put the plaintiffs in the position it would have occupied had the tort not been committed. In other words, a successful plaintiff is entitled to be put in the position it would have been in had the representation not been made."

[178] Mr. Rosen's damage calculation, based upon Experian's fraudulent misrepresentations, attempts to do exactly that. It calculates the cost to BDC of the 18 months Mr. Rosen assumes that BDC dealt unsuccessfully with Experian in reliance upon its employees' misrepresentations. Put another way, but for Experian's employees' fraudulent misrepresentations, BDC would not have wasted 18 months dealing with them. According to Mr. Rosen, BDC is entitled to be put in the position it would have been in if Experian had not made misrepresentations about its software and this calculation of BDC's damages achieves that end.

[179] Experian's expert witness on damages, Mark Gain, was also qualified to give expert opinion evidence about the quantification of economic damages. He calculated BDC's losses on the basis of a 12-month delay resulting from Experian's alleged misrepresentations. In his opinion, on this basis, the appropriate range of BDC's damages is between $1.7 million to $9.37 million. He criticized Mr. Rosen's calculation of BDC's damages for the following reasons:

• Mr. Rosen's analysis ignores the fact that labour is a fixed cost at BDC since the number of employees at its business centres remained relatively fixed at approximately 1,000 employees from 2007 to 2015;

• Mr. Rosen's analysis assumes that BDC's employees were all working at full capacity when there is no evidence that they were;

• Changes in BDC's employees' productivity relied upon by Mr. Rosen may be due to factors other than the introduction of the CLICS software;

• BDC's increased productivity was not unique because it was also experienced by other banks during the same period;

• Mr. Rosen used pre-CLICS productivity ratios when he should have used post-CLICS productivity ratios;

• Mr. Rosen attributed 100% of the change in BDC's employees' productivity to the introduction of CLICS; and

• Mr. Rosen did not include the incremental costs of operating CLICS in his analysis.

[180] I do not accept Mr. Gain's criticism based upon BDC's fixed labour costs because it ignores the fact that BDC wanted to do more business with the same number of employees. CLICS allowed BDC to do this. I am satisfied that this was an economic benefit to BDC.

[181] Mr. Gain effectively admitted this under cross-examination when he testified as follows:

Q. Now, I would like you to assume for the purpose of our discussion that a business has a staff of two people. And I would like you to assume that it contracts to acquire a tool that will make its staff twice as efficient; in other words, one person can do the work of two. Can you make those assumptions?

A. Sure.

Q. That would be, I take it, to use our nomenclature, contracting for something that would be a productivity benefit. Is that fair?

A. That's fair, yes.

Q. Sure. And suppose that product activity benefit was supposed to be delivered on January 1st of a particular year and was delayed in its delivery until December 31st; in other words, it was a year late for the purpose of our example. Do you agree that the Company has suffered a loss, that loss being the delay of productivity benefit?

A. Yes.

Q. And do you agree with me that, if you look at the reduction of headcount, you would only identify the situation where the business had fired the person, but would not identify the situation where the business had kept both employees but given them additional things to do?

A. I think that's a fair analogy, yes.[^58]

[182] Mr. Rosen responded to Mr. Gain's suggestion that BDC's employees' productivity gains may be due to other factors in his Reply Report. He demonstrated that the ratio of loan acceptances to employees only increased on a per month basis before CLICS was introduced by 0.67%, whereas for the period after CLICS was launched the average monthly increase was 4.42%. I am satisfied that his analysis demonstrates that BDC's employees became significantly more productive after CLICS was introduced.

[183] I do not accept Mr. Gain's "Industry Analysis" set out in his Reply Report which is based upon his analysis of the annual reports of Canada's five major banks. He came to the conclusion that the increased productivity experienced by BDC was not due to the implementation of the CLICS software because these other banks experienced similar productivity gains. In my view, his comparison was flawed for the following reasons:

• Mr. Gain included all bank employees of the five banks and compared them to BDC's lending employees;

• He compared the dollar value of the banks' loans not the number of loans;

• He compared BDC with banks that provide residential mortgages and credit cards and lend to large businesses and Governments which BDC does not do;

• He considered a good deal of data from other banks that was inapplicable to BDC.

[184] Mr. Rosen responded to Mr. Gain's criticism of him for not including the incremental costs of operating CLICS in his analysis at para. 5.21-5.32 of his Reply Report. I accept his explanation which he summarized at paras. 5.31 and 5.32 as follows:

5.31 Based on the foregoing, we have identified potential recurring incremental costs of approximately $1.7 million per year that may have been required in order to realize the estimated annual benefits from CLICS over the long-term.

5.32 However, due to the uncertainty with respect to the recurring incremental costs, and the amount and timing of future capital costs for both CLICS and CREM, we have not adjusted our damages calculations for these potential additional costs. In the FTI Supplemental Report we noted that for our alternative calculations, we did not include the employee fringe benefits identified by BDC in its own calculations of the economic benefits as we were unable to verify BDC's figures based on the information provided. We note that the amount of the employee fringe benefits and other employee costs identified by BDC are well in excess of the estimated incremental recurring costs noted in the October 2015 Business Case Update and would serve to more than offset any reduction for recurring incremental costs. …[^59]

[185] I am satisfied that Mr. Rosen provided reasonable responses in his Reply Report and during his oral testimony to all of Mr. Gain's technical criticisms of his damages calculation. I accept Mr. Rosen's damages analysis. In my view it is a reasonable and accurate way to quantify BDC's damages resulting from Experian's fraudulent misrepresentations.

[186] However, Mr. Gain also challenged Mr. Rosen's assumption that the duration of BDC's loss period resulting from Experian's fraudulent misrepresentations is 18 months. Mr. Gain suggested that this period should be less. In his calculations, he assumed a period of 12 months. His reasons for suggesting a shorter delay period were as follows:

• Some of the time spent with Experian was not wasted: BDC's November 2009 presentation noted the $430,000 spent with Experian was a cost that would result in future benefit to BDC;

• BDC would have spent time with other vendors before ultimately embarking on CLICS;

• BDC should have terminated the Agreement with Experian upon finding out that there was no "Base Product."

[187] Mr. Wall, in his Closing Submissions, stated as follows:

In the event the Court finds that Experian made fraudulent misrepresentations in its May 2008 response to BDC's RFI, such misrepresentations ceased to influence BDC's actions on June 5, 2009, after which BDC allegedly knew the true state of affairs. Therefore the proper measure of loss under BDC's tort claim is the period from May 28, 2008 to June 5, 2009, or approximately 12 months.

[188] I agree with Mr. Gain and Mr. Wall that the duration of the delay period should be less than 18 months for the reasons they have suggested. As of June 5, 2009, Ms. Boutin was aware that Experian did not have a base product with the attributes described in Experian's response to BDC's RFI. I am satisfied that it was reasonable for BDC to continue working with Experian to see what it could salvage from the situation it found itself in. BDC was attempting to reasonably mitigate its damages resulting from Experian's fraudulent misrepresentations. However, it cannot be said that that BDC continued to deal with Experian after June 5, 2009 as a result of its reliance upon Experian's fraudulent misrepresentations. I am not persuaded that it is reasonable for Mr. Rosen to assume that this entire six-month period was wasted solely because of Experian's fraudulent misrepresentations. As reasonable as it may have been to continue working with Experian, BDC made an informed business decision to continue working with Experian during this period despite its knowledge of Experian's fraudulent misrepresentations. Accordingly, Experian's fraudulent misrepresentations ceased to influence BDC's actions during this period.

[189] Considering all of these factors I have concluded that the appropriate delay period that should be used for the time BDC wasted dealing with Experian is 15 months. When Mr. Rosen's calculation of BDC's loss of economic benefits is adjusted using a 15-month delay period, BDC's loss is $41,140,416. In my view this is the most accurate measure of BDC's damages for its loss of economic benefits arising from Experian's fraudulent misrepresentations.

[190] There appears to be no dispute about Mr. Rosen's calculation of the incremental costs incurred by BDC from its dealings with Experian in the amount of $3,307,037. When this figure is added to BDC's damages for its loss of economic benefits, BDC's total damages are $44,447,453. This amount is, of course, exclusive of pre-judgment interest.

Punitive Damages

[191] BDC seeks punitive damages of $500,000 against Experian. Paragraph 38 of BDC's Written Closing Argument summarizes when punitive damages are available as follows:

38. Punitive damages are available when the defendant's conduct was "malicious, oppressive and high-handed" such that it "offends the court's sense of decency", and concerns "misconduct that represents a marked departure from ordinary standards of decent behavior". Punitive damages are only rational if compensatory damages do not adequately achieve the objective of retribution, deterrence and denunciation.

[192] Punitive damages against Experian are not warranted in this case. In my view, compensable damages of over $44 million more than adequately achieves the objectives of retribution, deterrence and denunciation. In coming to this conclusion I rely upon the Supreme Court of Canada's decision in Performance Industries v. Sylvan Lake Golf & Tennis Club[^60] where Binnie J. stated as follows:

… Indeed fraud is generally reprehensible, but only in exceptional cases does it attract punitive damages. … However, it must be kept in mind that an award of punitive damages is rational 'if, but only if' compensatory damages do not adequately achieve the objectives of retribution, deterrence and denunciation.

Is Experian entitled to the payment of one-half of the outstanding Development Charges under the Agreement?

[193] In view of my conclusion that Experian breached the Agreement, Experian is not entitled to any payments under the Agreement. This includes one-half of the Development Charges.

Conclusion

[194] For the reasons outlined above, BDC's claim for damages arising from Experian's fraudulent misrepresentations is allowed. BDC's damages are assessed in the amount of $44,447,416. BDC shall have judgment against Experian Canada and Experian US in this amount plus pre-judgment and post-judgment interest calculated in accordance with the Courts of Justice Act.

Costs

[195] If the parties cannot settle costs they may file brief written submissions of no more than three pages with costs outlines within 30 days.

[196] I sincerely thank all counsel for the very professional and efficient manner in which they conducted this proceeding.

HAINEY J.

Released: March 23, 2017

Appendix "A"

ANALYSIS OF PROFESSOR MURPHY

1. Professor Murphy based her answer on the literature with respect [to] the software product line approach, which approach is grounded in certain well understood benefits to the software provider and customer, including reduced cost, higher quality product since it has been tested and a product adapted to customer needs that evolves over time. In cross-examination, Mr. Mehta admitted these same benefits and that he understood that BDC expected to have all of those advantages.

2. Professor Murphy when [sic] on to derive, and analyze the software Experian provided to her in accordance with, three criteria that must, in her expert opinion, be met as to whether a base solution existed. The criteria were: (1) Core Assets: Are there identifiable, high-quality core assets (e.g., source code or designs) that form the majority of the software products? (2) Managed Development of Core Assets: Is there a well-defined process for maintaining and evolving the core assets? (3) Variability Mechanism: Is there an approach or mechanism to support management of the commonalities between software products as well as the variabilities needed to support features in particular software products? Experian did not challenge the application of the software product line approach or these three criteria.

3. She found that the first two of these criteria were not met and that all had to be met in order for a base solution to exist. Experian did not challenge these conclusions.

4. With respect to the first criteria, core assets, Professor Murphy looked at three characteristics to see whether in her opinion they were satisfied: (1) Identifiable Core Assets: Are there core assets identifiable in the software development? (2) Reuse: Do the source code core assets form the majority of a software product such that the product benefits from substantial reuse of existing high-quality assets? (3) Tests: Are there tests for the source code core assets, irrespective of the asset's use in an individual product? Her conclusion was there was no evidence of the first and third characteristics (i.e. no evidence of identifiable core assets and no evidence of tests of core assets). All three characteristics had to be present in order to conclude that the core assets criterion as [sic] met. The second of those characteristics, reuse, for which Professor Murphy found some evidence, consisted of three separate analyses to assess the degree of use: (1) a filename comparison, (2) a classname comparison, and (3) a multi-system class comparison.

5. While an issue with respect to her analysis of the filename comparison analysis that related to the reuse characteristic was pointed out on cross-examination, Professor Murphy was clear that she did not rely solely on the filename comparison when she looked at reuse, as she also performed two other analysis [sic] involving classname comparison and multi-system class comparison. Those other two analyses were not undermined on cross-examination.

CITATION: Business Development Bank of Canada v. Experian Canada Inc., 2017 ONSC 1851

COURT FILE NO.: CV-10-405324

DATE: 20170323

ONTARIO

SUPERIOR COURT OF JUSTICE

BETWEEN:

BUSINESS DEVELOPMENT BANK OF CANADA

Plaintiff

– and –

EXPERIAN CANADA INC. and EXPERIAN INFORMATION SOLUTIONS, INC.

Defendants

AND BETWEEN:

EXPERIAN CANADA INC. and EXPERIAN INFORMATION SOLUTIONS, INC.

Plaintiffs by Counterclaim

– and –

BUSINESS DEVELOPMENT BANK OF CANADA

Defendant by Counterclaim

REASONS FOR JUDGMENT

HAINEY J.

Released: March 23, 2017

[^1]: Anne Boutin trial testimony, Day 1, April 18, 2016, p. 132:11 – 133:4. [^2]: Edmée Métivier trial testimony, Day 13, May 11, 2016, p. 1802:4 – 1802:15. [^3]: Anne Boutin trial testimony, Day 1, April 18, 2016, p. 135:15 – 135:19. [^4]: Anne Boutin trial testimony, Day 1, April 18, 2016, p. 135:19 – 135:23. [^5]: Anne Boutin trial testimony, Day 1, April 18, 2016, p. 134:4 – 134:25. [^6]: Brian Eatock trial testimony, Day 4, April 21, 2016, p. 500:17 – 502:15. [^7]: Brian Eatock trial testimony, Day 4, April 21, 2016, p. 505:17 – 506:24. [^8]: Anne Boutin trial testimony, Day 1, April 18, 2016, p. 138:14 – 138:22. [^9]: Exhibit 1, JDB 147, BDC Vendor Pre-Qualification Questionnaire. [^10]: Anne Boutin trial testimony, Day 1, April 18, 2016, p. 144:24 – 146:22. [^11]: Brian Eatock trial testimony, Day 4, April 21, 2016, p. 523:21 – 525:8. [^12]: Brian Eatock trial testimony, Day 4, April 21, 2016, p. 529:16 – 529:22. [^13]: Exhibit 1, JDB 158, BDC Vendor Questionnaire Background. [^14]: Exhibit 1, JDB 168, Letter from Bill Busch. [^15]: Exhibit 1, JDB 168, Experian's responses to RFI Spreadsheet. [^16]: Chris Daily trial testimony, Day 13, May 11, 2016, p. 1720:19 – 1740:6. [^17]: Chris Daily trial testimony, Day 13, May 11, 2016, p. 1754:6 – 1755:25. [^18]: Chris Daily trial testimony, Day 13, May 11, 2016, p. 1761:13 – 1762:10. [^19]: Chris Daily trial testimony Day 13, May 11, 2016, p. 1758:15 – 1759:15. [^20]: Exhibit 1, JDB 197, Solution Recommendation PowerPoint. [^21]: Anne Boutin trial testimony, Day 2, April 19, 2016, p. 226:11 – 226:18. [^22]: Vijay Mehta trial testimony, Day 9, May 2, 2016, p. 1133:22 – 1135:21. [^23]: Exhibit 1, JDB 275, BDC A&E Business Case and Roadmap. [^24]: Exhibit 1, JDB 465, Experian e-mail dated April 24, 2009. [^25]: Bill Busch trial testimony, Day 15, June 6, 2016, p. 2073:21 – 2074:21. [^26]: Chris Daily trial testimony, Day 12, May 10, 2016, p. 1672:9 – 1673:13. [^27]: Exhibit 1, JDB 291 Experian e-mail dated December 24, 2008. [^28]: Exhibit 1, JDB 348 Experian e-mail dated March 2, 2009. [^29]: Vijay Mehta trial testimony, Day 9, May 2, 2016, p. 1262:19 – 1263:24. [^30]: Exhibit 1, JDB 374 Experian e-mail dated March 4, 2009. [^31]: Exhibit 1, JDB 420 Experian e-mail dated March 30, 2009. [^32]: Exhibit 1, JDB 351 Experian e-mail dated May 21, 2009. [^33]: Vijay Mehta trial testimony, Day 10, May 3, 2016. [^34]: Anne Boutin trial testimony, Day 2, April 19, 2016, p. 291:20 – 293:9. [^35]: Exhibit 1, JDB 703, Experian e-mail dated July 21, 2009. [^36]: Eric Marineau trial testimony, Day 5, April 25, 2016, p. 761:18 – 766:3. [^37]: Chris Daily trial testimony, Day 13, May 11, 2016, p. 1776:5-10. [^38]: Anne Boutin trial testimony, Day 2, April 19, 2016, p. 229:23 – 302:18. [^39]: Chantal Belzile trial testimony, Day 5, April 25, 2016, p. 608:2 – 610:14. [^40]: Anne Boutin trial testimony, Day 2, April 19, 2016, p. 330:10-19. [^41]: Anne Boutin trial testimony, Day 2, April 19, 2016, p. 306:7 – 308:6. [^42]: Exhibit 1, JDB 638 Update to Business case dated June 17, 2009. [^43]: Exhibit 1, JDB 810 Experian e-mail dated September 3, 2009. [^44]: Edmée Métivier trial testimony, Day 13, May 11, 2016, p. 1814:18 – 1815:18. [^45]: Edmée Métivier trial testimony, Day 13, May 11, 2016, p. 1816:5-25. [^46]: Edmée Métivier trial testimony, Day 13, May 11, 2016, p. 630:13 – 633:15. [^47]: Chantal Belzile trial testimony, Day 5, April 25, 2016, p. 670:8-24. [^48]: Chantal Belzile trial testimony, Day 5, April 25, 2016, p. 671:7-20. [^49]: Exhibit 1, JDB 982 Letter from Paul Buron to Experian dated November 19, 2009. [^50]: Pierre Dubreuil trial testimony, Day 6, April 26, 2016, p. 828:16 – 829:12. [^51]: Eric Carrière trial testimony, Day 5, April 25, 2016, p. 789:11 – 797:12. [^52]: Eric Carrière trial testimony, Day 5, April 25, 2016, p. 802:5 – 19. [^53]: Gail Murphy trial testimony, Day 7, April 27, 2016, p. 899:5-25. [^54]: 1993 146 (SCC), [1993] 1 S.C.R. 87 at paras. 72 and 73. [^55]: (1985), 31 A.C.W.S. (2d) 326 at para. 20. [^56]: 961 F (2d) 620 at 623 (7th Cir. 1992). [^57]: Exhibit 9, Expert Report of Howard N. Rosen and Chris Milburn, FTI Consulting Inc. dated November 20, 2015. [^58]: Mark Gain trial testimony, Day 14, May 12, 2016, p. 1956:2-24, 1956:3-11. [^59]: Exhibit 9, Reply Report of Howard N. Rosen and Chris Milburn, FTI Consulting Inc. dated March 22, 2016. [^60]: 2002 SCC 19, [2002] 1 S.C.R. 678 at para. 87.