Equifax Information Services, LLC
B-414907: Oct 16, 2017
- Full Report:
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.
DOCUMENT FOR PUBLIC RELEASE
The decision issued on the date below was subject to a GAO Protective Order. This redacted version has been approved for public release.
Matter of: Equifax Information Services, LLC
Date: October 16, 2017
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.
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 holding the financial and business solutions schedule contract, special item number 520-16. 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; 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 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.
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. 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.
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.
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 FARA protester’s disagreement with the agency’s judgment does not establish that an evaluation was unreasonable. 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. .
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. 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, 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. 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.
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
 These vendors were the three national credit bureau companies: Equifax, Experian, and TransUnion.
 The solicitation was amended twice. All references in this decision are to the final amended version of the RFQ unless otherwise stated. Additionally, we added consecutive numbers to the pages of this tab.
 As relevant here, the solicitation defined KBA and OOW as types of transactions that allow a person to identify themselves to a third party or system using information that could be found in a person’s wallet or would normally be known only to that person. RFQ at 4. The solicitation provided that these terms (KBA and OOW) could be used interchangeably. Id.
 The solicitation does not define the process that would be used to “vet” API connections.
 In this regard, we note that Equifax did not protest the terms of the solicitation prior to submitting its quotation.
 Our Office added consecutive numbers to the unnumbered pages of this tab.
 Our Office concluded that additional information was required to understand the agency’s vetting and testing process. Accordingly, the GAO attorney responsible for this protest posed specific questions to the parties related to issues identified in the record. GAO Email to Parties, September 19, 2017.
 The agency explains that proofing types are different types of information that can be used for identity verification. Agency Response to GAO Questions at 3.
 The agency explains that KBA uses knowledge based questions as part of the authentication process. Id.
 On October 6, the protester supplemented its arguments based on new information gained through the agency’s September 30 award of a sole-source, three-month contract to Equifax during the pendency of this protest. Protester Email to GAO, October 6, 2017. The protester contends that actions taken by the agency in the context of the sole-source contract--for example, certain revisions to the text of the sole-source solicitation--call into question the arguments made by the agency in this protest. Id. Since each federal procurement stands on its own, we find no basis to conclude that the agency’s actions taken in relation to the sole-source contract demonstrate that the agency’s actions or arguments related to this procurement and protest were unreasonable. See Wego, Inc., B-405673.3, May 21, 2012, 2012 CPD ¶ 161 at 3; District Moving & Storage, Inc. et al., B-272070, Aug. 9, 1996, 96-2 CPD ¶ 60 at 3.