Equifax Information Services, LLC

Decision

Matter of:  Equifax Information Services, LLC

File:  B-414907

Date:  October 16, 2017

DIGEST

Protest challenging an agency’s evaluation of an awardee’s quotation is denied where the awardee’s quotation met the solicitation’s technical requirements and the agency’s evaluation was reasonable and consistent with the stated evaluation criteria.

Equifax Information Services, LLC (Equifax), of Lanham, Maryland, the incumbent contractor, protests the establishment of a blanket purchase agreement (BPA) with Experian Information Solutions (Experian), of Costa Mesa, California, under request for quotations (RFQ) No. TIRNO-17-Q-00047 issued by the Department of the Treasury, Internal Revenue Service (IRS), for taxpayer identity and verification services.  Equifax challenges the agency’s evaluation of the awardee’s quotation.

We deny the protest.

BACKGROUND

On June 13, 2017, the IRS issued the RFQ under the federal supply schedule (FSS) procedures of Federal Acquisition Regulation (FAR) subpart 8.4 to three vendors[1] holding the financial and business solutions schedule contract, special item number 520-16.[2]  The RFQ contemplated the issuance of a fixed-price task order with a 12-month period of performance.  Agency Report (AR), Tab D.3a, RFQ at 1, 6.  Award was to be made on a lowest-price, technically acceptable basis.  Id. at 1. 

The RFP’s statement of work (SOW) explained that with this BPA, the IRS would be able to use the proprietary databases of the successful vendor to verify the identity of a taxpayer, thereby reducing or preventing tax refund fraud caused by identify theft.  Id. at 4.

The SOW defined the scope and objectives of the solicitation, and stated that the IRS was seeking data products and capabilities, such as: knowledge based authentication (KBA); out of wallet (OOW) information;[3] telephone transactions; and financial transactions/account verification services (financial transaction services).  RFQ at 4.  As relevant here, financial transaction services were defined as transactions that use checking, savings, loans, credit cards, and utility account data to verify a person’s identity.  Id. at 4.  The SOW also listed, among the “scope and objectives,” the following five bullet points:

• Provision of individual based data authentication that can be used in real time to verify a caller’s identity,
• Question support based on Out of Wallet (OOW) information,
• Phone verification to include number validation with the identity,
• Financial data validation (e.g., checking, savings, loans, credit cards, and utility account data),
• Question support based on known Knowledge Based Authentication (KBA)

Id. at 5.

Additionally, the RFQ required offerors to have previously demonstrated the ability to connect to the IRS system via an application programming interface (API) that had been vetted[4] prior to award.  RFQ, SOW at 5.  The RFQ advised that the ability to connect would be needed within one week of when the BPA was established.  Id.

The RFQ required a contractor to perform two tasks, including, as relevant here, transaction support services that would cover, at a minimum, the provision of OOW, KBA, phone or financial transactions to verify the asserted identity of a caller or user of web services. RFQ at 5.  The RFQ did not specify precisely how these tasks would be evaluated.[5]

The agency received quotations from Experian and Equifax.  Contracting Officer’s Statement at 3.  As relevant here, for financial transaction services, Experian proposed “to validate and verify various accounts associated with an individual[,] such as credit card, mortgage loan, home equity loan, home equity line of credit, auto loan, and student loan.”  AR, Tab F, Experian Quotation, at 7. 

A technical evaluation team initially evaluated quotations and provided its evaluation results to the contracting officer, who was the source selection authority (SSA) for the competition.  Id.  Based on the evaluation of the vendors’ quotations, the SSA stated that both firms met the technical requirements, demonstrated an ability to connect to the IRS systems via an API that had been vetted prior to award, and showed the ability to provide support and services associated with the integration of the contractor identity data services into the existing IRS business environment.  AR, Tab G.1, Award Decision, at 3.[6]  Equifax’s total evaluated price was $2,591,200; Experian’s was $795,200.  Id. at 2.  The SSA selected Experian as offering the lowest-priced, technically acceptable quotation.  Id. at 4. 

On June 30, Equifax was notified of the award and requested a debriefing.  On July 5, the agency provided Equifax a brief explanation of award.  This protest timely followed on July 7. 

DISCUSSION

The protester asserts that Experian’s quotation should have been evaluated as unacceptable because Experian failed to meet the API requirement and did not offer services required by the solicitation.  We have reviewed all of the protester’s various arguments and conclude that none furnishes a basis to sustain the protest.

API Connection

Equifax asserts that the awardee did not meet the requirement to have an existing API service connection, and that even if the awardee did achieve an API service connection, it would not have been mature enough to operate within one week as specified by the RFQ.  Protest at 7. 

Where, as here, an agency issues an RFQ to FSS vendors under FAR subpart 8.4 and conducts a competition for the issuance of an order or establishment of a BPA, we will review the record to ensure that the agency’s evaluation was reasonable and consistent with the terms of the solicitation and applicable procurement laws and regulations. CliftonLarsonAllen, LLP, B-412938, B-412938.2, July 11, 2016, 2016 CPD ¶ 204 at 4.  A protester’s disagreement with the agency’s judgment does not establish that an evaluation was unreasonable.  DEI Consulting, B-401258, July 13, 2009, 2009 CPD ¶ 151 at 2. 

Before the filing of the agency report, the agency requested dismissal of the protest, which we declined to grant based on the arguments raised by the protester below.  The IRS asserted that Experian had successfully demonstrated an existing API connection in August 2016, and the agency provided a contemporaneous email detailing the steps taken to vet Experian’s API (August 2016 email).  Dismissal Request at 5; Dismissal Request, Exh. 2, Experian Technical Integration Email, Aug. 22, 2016.  That email, after concluding that the agency had “successfully wrapped up Experian [t]echnical [i]ntegration efforts” as of August 19, 2016, included a section titled “next steps and deferred issues.”  Id.  In this section, the email stated, “knowledge based question (KBA) defect resolution (deferred issue) may need to be resolved if KBA capabilities are to be utilized.  This issue was deferred as the proofing types . . . [are] not actively used or likely to be used by eAuth going forward.”  Id.  Based on that statement, the protester questioned whether the agency had fully vetted Experian’s API connection for knowledge-based question/authentication services.  Protester’s Response to Dismissal Request at 4.  We asked the agency to respond to this argument in its agency report. 

In its report, received by our Office on August 7, the agency states that the August 2016 email demonstrated that Experian’s API was vetted prior to award, and successfully completed extensive testing across the three external data products or “proofing types” used in the IRS eAuthentication system.  Memorandum of Law (MOL) at 4-5.  The agency further explains that an API is a software-to-software interface that enables two applications to communicate and exchange data with each other.  Agency Response to GAO Questions at 2, Agency Email to GAO, September 21, 2017.[7]  The successful demonstration of an API is achieved by:  (1) establishing a trusted connection and (2) exchanging request and response actions.  Id. at 3-4.  In this regard, the agency identified the specific portions of the August 2016 email showing that Experian’s API had successfully met these two elements for each of the three required proofing types,[8] i.e., OOW/KBA, telephone transactions, and financial transaction services. Id.

Additionally, the agency notes that in response to the dismissal request, the protester incorrectly characterized the KBA deferral issue as a “defect” or issue that requires resolution by the awardee.  The agency states that--contrary to the protester’s assertions--the KBA deferral issue was based on the limitations of the IRS’s system and therefore would require resolution regardless of the contractor receiving award.  MOL at 6.  In this regard, the agency explains that because the IRS system was not currently using, or likely to use, KBA capabilities, the IRS had deferred the resolution of the utilization of KBA capabilities.  Id.  Moreover, the agency advised that for a single entry point API, like the one used by Experian, KBA does not play a role in demonstrating an API.  Agency Response to GAO Questions at 3-4, Agency Email to GAO, September 21, 2017.

We find no merit to the protester’s assertion that Experian failed to meet the API requirement.  In this regard, the record shows that in August 2016, the agency vetted Experian’s ability to connect to the IRS system via an API by ensuring that Experian’s API could establish a trusted connection and exchange request and response actions.  The record also shows that the IRS specifically considered Experian’s API connection for knowledge-based question/authentication services.  In this regard, the agency found “successful . . . knowledge based question & identity + knowledge based question proofing types” in the vetting process.[9]  Request for Dismissal, Exh. 2, Experian Technical Integration Email, Aug. 22, 2016.  Finally, the record shows that the agency reasonably concluded that Experian met the solicitation requirements, including demonstrating the ability to connect to the IRS’s system via an API.  AR, Tab G.1, Award Decision, at 3.  Based on our review of the record, the protester’s remaining challenges, including its various KBA arguments, do not show that the agency’s evaluation was unreasonable.[10]

Financial Transactions

The protester next contends that the agency erred in finding Experian’s quotation technically acceptable because Experian’s low price should have caused the agency to question whether the firms understood and were responding to the same requirements.  Protest at 7-8.  In this regard, the protester argues that the solicitation’s provisions regarding verifying a taxpayer’s identity through financial transaction services and financial data validation required firms to offer all five of the transaction types included in the definition of financial transaction services.  Protester’s Comments at 6.  The protester asserts that Experian’s failure to provide all the transaction types should have resulted in its quotation being found unacceptable.  Protest at 8; Protester’s Comments at 4.

The solicitation includes two relevant references to financial information: (1) in a list explaining the types of data products and capabilities the IRS was seeking, a definition of financial transaction services as being transactions that use checking, savings, loans, credit cards, and utility account data to verify a person’s identity; and (2) among bullet points that address the means of analyzing the effectiveness of various transactions in verifying a taxpayer’s identity, a clause that states, “financial data validation (e.g., checking, savings, loans, credit cards, and utility account data).”  RFQ at 4-5.

The IRS disagrees with the protester’s arguments and asserts that neither provision, nor the RFQ generally, required firms to offer all transaction types.  MOL at 10-11.  Rather, the agency asserts that both provisions offered examples to “serve as an illustration . . . not a definitive or detailed list of every conceivable iteration possible or required,” and that a firm was expected to offer the solution it deemed appropriate.  Id. at 11.  We agree with the IRS.

Where, as here, a dispute exists as to the actual meaning of a particular solicitation provision, our Office will resolve the matter by reading the solicitation as a whole and in a manner that gives effect to all its provisions; to be reasonable, an interpretation of a solicitation must be consistent with such a reading.  Tetra Tech AMT, B-411934.2, B-411934.3, May 17, 2016, 2016 CPD ¶ 136 at 5; Alluviam LLC, B-297280, Dec. 15, 2005, 2005 CPD ¶ 223 at 2. 

Based on our review, we do not find the protester’s interpretation of the solicitation to be reasonable.  In this regard, the RFQ did not require a firm to provide all five financial transaction types in order to be technically acceptable.  Moreover, because the solicitation did not specifically identify how quotations would be evaluated, there is no basis to conclude that a quotation would be found unacceptable if it failed to offer each transaction type.  On the record here, we find reasonable the agency’s conclusion that Experian’s quotation was acceptable, and deny Equifax’s contentions to the contrary. 

The protest is denied.

Susan A. Poling
General Counsel