Bats Global Markets Holdings, Inc. and Subsidiaries

• Court: United States Tax Court
• Decided: March 31, 2022
• Docket: 1068-17
• Status: Published

Opinion

United States Tax Court

158 T.C. No. 5

BATS GLOBAL MARKETS HOLDINGS, INC. AND SUBSIDIARIES, Petitioner

v.

COMMISSIONER OF INTERNAL REVENUE, Respondent

—————

Docket No. 1068-17. Filed March 31, 2022.

P, an operator of national securities exchanges, charged its customers certain fees in connection with their participation on the exchanges (Fees). P developed computer software that it used to operate the exchanges. P treated the gross receipts from the Fees as domestic production gross receipts (DPGR) for the purpose of calculating deductions pursuant to I.R.C. § 199, which it claimed with respect to years 2011–13. R determined that none of the gross receipts from the Fees were DPGR.

Under the applicable regulations, a taxpayer is entitled to treat as DPGR gross receipts derived from providing customers access to computer software for the customers’ direct use. Treas. Reg. § 1.199-3(i)(6)(iii). Further, a third party must derive gross receipts from the disposition in a tangible medium or by download of substantially identical software (as compared to the taxpayer’s software) to its customers. Id. subdiv. (iii)(B).

Held: P is not entitled to treat the gross receipts from the Fees as DPGR under Treas. Reg. § 1.199-3(i)(6)(iii) because the Fees were not derived from providing customers access to computer software for their direct use.

Served 03/31/22 2

Held, alternatively, P is not entitled to treat the gross receipts from the Fees as DPGR because the third- party software proposed as comparable by P was not substantially identical software as compared to P’s software. See id. subdiv. (iii)(B).

Mario J. Verdolini, Jr., Christopher A. Baratta, and Lara S. Buchwald, for petitioner.

Andrew Michael Tiktin, M. Jeanne Peterson, Tatiana Belenkaya, David B. Flassing, Henry C. Bonney, and Erin H. Stearns, for respondent.

KERRIGAN, Judge: Respondent issued a notice of deficiency determining deficiencies of $932,713, $1,319,418, and $1,425,984 for tax years 2011, 2012, and 2013 (years in issue), respectively. Petitioner timely sought redetermination in this Court. After concessions the issue for consideration is whether petitioner’s transaction fees, routing fees, and logical port fees (collectively, Fees) qualify as domestic production gross receipts (DPGR) for the purpose of calculating deductions pursuant to section 199.

Unless otherwise indicated, all statutory references are to the Internal Revenue Code, Title 26 U.S.C., in effect at all relevant times, all regulation references are to Code of Federal Regulations, Title 26 (Treas. Reg.), in effect at all relevant times, and all Rule references are to the Tax Court Rules of Practice and Procedure. We round all monetary amounts to the nearest dollar.

On December 16, 2019, the Court issued a protective order to prevent disclosure of petitioner’s proprietary and confidential information. The facts and opinion have been adapted accordingly, and information set forth herein is not proprietary or confidential.

FINDINGS OF FACT

I. Overview of Bats Global

BATS Global Markets Holdings, Inc. (Bats Global), is, and was during the years in issue, a Delaware corporation with its principal place of business in Lenexa, Kansas. During the years in issue Bats Global 3

was named BATS Global Markets, Inc., and owned 100% of BATS Exchange, Inc., BATS Y-Exchange, Inc., and BATS Trading, Inc. Bats Global was the common parent of a group of corporations (collectively, petitioner) which filed consolidated U.S. federal income tax returns for the years in issue. On February 28, 2017, petitioner became a subsidiary of Cboe Global Markets, Inc.

Bats Global was founded in mid-2005. “BATS” was an acronym of “Better Alternative Trading System.” The name referred to an alternative trading system, a type of venue for matching buyers and sellers of securities that is subject to regulation different from that of a national securities exchange. See 17 C.F.R. § 242.300(a) (2009). Petitioner initially operated an alternative trading system. By the years in issue its exchanges were registered as national securities exchanges.

From mid-2005 through January 2006, petitioner’s founders wrote software code for the trading of equity securities. In 2006 petitioner launched a trading platform using the software it had developed. By the end of 2007 petitioner had developed its trading platform software to allow for the trading of all U.S. equity securities. By the years in issue petitioner had become the third-largest operator of equities exchanges in the United States after NYSE Euronext and NASDAQ OMX Group, Inc.

During the years in issue petitioner developed and operated electronic markets for the trading of listed cash equity securities in the United States and Europe and listed equity options in the United States. It did not have any physical location where buyers and sellers could meet to engage in trading. In the years in issue petitioner had 85 to 108 employees, who were divided into the following departments: business development and marketing; communications; compliance, surveillance and membership services; corporate and legal; finance; human resources; infrastructure; operations; sales; and software development.

Petitioner operated two marketplaces for purchasers and sellers of securities: BATS Exchange (BZX) and BATS Y-Exchange (BYX). BZX and BYX targeted different market segments by offering different pricing structures. Petitioner also operated a marketplace for trading listed equity options as part of BZX, referred to as BATS Options.

II. Regulation of the Exchanges

BZX, BYX, and BATS Options (collectively, Exchanges) were registered with and regulated by the U.S. Securities and Exchange 4

Commission (SEC) during the years in issue. The SEC had primary responsibility for enforcing the federal securities laws and regulations and could prohibit exchanges that violated the law from operating.

The Exchanges were treated as national securities exchanges pursuant to the Securities Exchange Act of 1934 (1934 Act), ch. 404, 48 Stat. 881 (codified as amended at 15 U.S.C. §§ 78a–78pp (2012)). A national securities exchange is defined as any exchange registered pursuant to 15 U.S.C. § 78f. 17 C.F.R. § 242.600(b)(45) (2005).

In 2006 petitioner launched the predecessor to BZX, an exchange that used maker-taker pricing. See infra Section V.B.3. Transaction Fees. Petitioner launched BATS Options as part of BZX in 2010. BATS Exchange, Inc., was responsible for regulatory filings with respect to BZX and BATS Options. The SEC approved the application of BZX to register as a national securities exchange on August 18, 2008, and trading commenced on October 24, 2008. The SEC approved BATS Options as part of BZX on January 26, 2010, and trading commenced on October 15, 2010.

In 2010 petitioner launched BYX, an exchange that used taker- maker pricing. See infra Section V.B.3. Transaction Fees. BATS Y- Exchange, Inc., was responsible for regulatory filings with respect to BYX. On August 13, 2010, the SEC approved the application of BYX to register as a national securities exchange, and trading commenced on October 15, 2010.

A. Securities Exchange Act of 1934

For the Exchanges to be designated national securities exchanges, certain statutory requirements needed to be met. See 15 U.S.C. § 78f(b). A national securities exchange must comply with the 1934 Act and be able to enforce compliance by its members and persons associated with its members. Petitioner was required to ensure that quotation information supplied to investors and the public was fair and informative, and not discriminatory, fictitious, or misleading.

The SEC reviewed the Exchanges to ensure that they had the capacity to carry out the purposes of the 1934 Act. Upon granting the Exchanges’ applications to register as national securities exchanges, the SEC found that the Exchanges’ rules were designed to facilitate transactions in securities, promote just and equitable principles of trade, prevent fraudulent and manipulative acts and practices, and protect investors and the public interest. 5

Regulations under the 1934 Act specify that the exchange itself “[b]rings together the orders for securities of multiple buyers and sellers” and “[u]ses established, non-discretionary methods (whether by providing a trading facility or by setting rules) under which such orders interact with each other, and the buyers and sellers entering such orders agree to the terms of a trade.” 17 C.F.R. § 240.3b-16(a) (2005). Under the 1934 Act an “exchange” means

any organization, association, or group of persons, whether incorporated or unincorporated, which constitutes, maintains, or provides a market place or facilities for bringing together purchasers and sellers of securities or for otherwise performing with respect to securities the functions commonly performed by a stock exchange as that term is generally understood, and includes the market place and the market facilities maintained by such exchange.

15 U.S.C. § 78c(a)(1). The term “facility” includes an exchange’s

premises, tangible or intangible property whether on the premises or not, any right to the use of such premises or property or any service thereof for the purposes of effecting or reporting a transaction on an exchange (including, among other things, any system of communication to or from the exchange, by ticker or otherwise, maintained by or with the consent of the exchange), and any right of the exchange to the use of any property or service.

15 U.S.C. § 78c(a)(2).

B. Regulation National Market System

Petitioner’s Exchanges were also subject to the Regulation National Market System (Regulation NMS), a set of rules promulgated by the SEC in 2005. 70 Fed. Reg. 37,496 (June 29, 2005); 17 C.F.R. §§ 242.600–242.612 (2005). For example, the Regulation NMS limited petitioner’s transaction fees to a specified amount or percentage per share. 17 C.F.R. § 242.610(c).

Another of the rules set forth in the Regulation NMS is the order protection rule, which generally does not permit national securities exchanges to execute customers’ orders at a price other than the best available ask price when buying securities and the best available bid 6

price when selling securities (also known as the national best bid or offer, or NBBO). 17 C.F.R. § 242.611; see also id. § 242.600(b)(42) (defining NBBO). A bid is an order to buy at a certain price and an offer is an order to sell at a certain price. See 17 C.F.R. § 242.600(b)(8). The term “order” means “any firm indication of a willingness to buy or sell a security, as either principal or agent, including any bid or offer quotation, market order, limit order, or other priced order.” Id. § 240.3b- 16(c). For purposes of the Regulation NMS the best bid and best offer mean the highest priced bid and the lowest priced offer. Id. § 242.600(b)(7). If a competing exchange has a better price than that offered on the exchange that received the order, the order must be routed to the exchange with the better price.

To ensure compliance with the order protection rule, petitioner’s trading software was coded so that there could not have been executions on the Exchanges without the market data from the consolidated tape reflecting the NBBO on other registered exchanges. The consolidated tape was generated by securities information processors operated by NASDAQ and a subsidiary of NYSE.

III. Bats Global Customers

Petitioner’s customers were organizations that were members of either BATS Exchange, Inc., or BATS Y-Exchange, Inc. In addition, members were able to sponsor their own customers to participate in trading on the Exchanges.

To become a member, a prospective customer was required to be registered as a broker-dealer with the SEC, be a member of at least one other national securities exchange or national securities association, be able to clear trades on its own or through a clearing firm, and meet additional prescribed criteria. During the years in issue prospective customers were required to fill out a membership application and to execute a user agreement and a securities routing agreement. There were no membership fees payable to petitioner. Members did not become stockholders of BATS Exchange, Inc., or BATS Y-Exchange, Inc.

Some of petitioner’s customers were broker-dealers affiliated with separate entities, such as banks, that operated their own electronic markets. These broker-dealers may have routed orders from their affiliates’ electronic markets to the Exchanges. Petitioner’s trading software would have received, handled, and processed orders routed to 7

petitioner’s Exchanges in the same way as orders from any of petitioner’s other customers.

A member of BATS Exchange, Inc., could also be authorized to become an options member and transact business on BATS Options. To become an options member, a BATS Exchange, Inc., member had to complete a separate application and an options member agreement.

A. Exchange Rules

By signing the membership application, a potential member agreed to abide by the rules of the relevant exchange (Exchange Rules) and “to pay such dues, fees, assessments, and other charges in the manner and amount as shall from time to time be fixed by the exchange.” Sponsored participants also agreed to abide by the Exchange Rules and executed a separate user agreement and a securities routing agreement with petitioner.

Exchange Rule 15.1 stated with respect to the fees of the Exchanges:

Rule 15.1 Authority to Prescribe Dues, Fees, Assessments, and Other Charges

(a) Generally. The Exchange may prescribe such reasonable dues, fees, assessments or other charges as it may, in its discretion, deem appropriate. Such dues, fees, assessments, and charges may include membership dues, transaction fees, communication and technology fees, regulatory charges, listing fees, and other fees and charges as the Exchange may determine. All such dues, fees and charges shall be equitably allocated among Members, issuers, and other persons using the Exchange’s facilities.

....

(c) Schedule of Fees. The Exchange will provide Members with notice of all relevant dues, fees, assessments, and charges of the Exchange. Such notice may be made available to Members on the Exchange’s website or by any other method deemed reasonable by the Exchange. 8

The Exchange Rules governed how the Exchanges operated, including how customers’ orders were handled and matched and how members were regulated. Exchange Rule 11.3 stated with respect to customers’ access to the Exchanges:

Rule 11.3. Access

(a) General. The System shall be available for entry and execution of orders by Users with authorized access. To obtain authorized access to the System, each User must enter into a User Agreement with the Exchange in such form as the Exchange may provide (“User Agreement”).

The Exchange Rules defined petitioner’s “System” as “the electronic communications and trading facility designated by the Board through which securities orders of Users are consolidated for ranking, execution, and when applicable, routing away.”

B. The User Agreement

The user agreement executed by petitioner and each customer provided that customers had the right to receive certain services from petitioner. The user agreement explained the services as follows:

2. Services. Subject to the terms and conditions of this Agreement, User will have the right to access Exchange to enter orders on Exchange, receive status updates on orders, cancel orders, execute trades against orders on the Exchange limit order book and to receive data feeds from Exchange (“Exchange Data”) containing information regarding User’s open orders, executions and volume on Exchange (collectively, the “Services”).

The user agreement explained that customers could be charged system usage fees as follows:

13. Fees. By signing this Agreement, User agrees to make timely payment of all system usage fees, as may be set forth in Exchange Rules or posted on Exchange’s web site. 9

C. The Securities Routing Agreement

Petitioner executed a securities routing agreement with each customer providing that petitioner’s subsidiary, BATS Trading, Inc., routed customers’ orders to marketplaces outside of the Exchanges. BATS Trading, Inc., was a registered broker-dealer and was able to submit orders to external markets, such as the New York Stock Exchange or NASDAQ, which required members to be broker-dealers.

The securities routing agreement was governed and interpreted in accordance with New York law. It provided as follows:

Provided that User is a Member or Sponsored Participant of a Member of [the relevant exchange] and subject to a valid, ongoing User Agreement with Exchange, BATS Trading, Inc. (hereinafter “BATS Trading”), a broker-dealer registered in accordance with Section 15(a) of the Securities Exchange Act of 1934, as amended (the “Act”), agrees to act as agent to User for the purpose of providing certain routing services, as described herein, provided that User is bound by the terms and conditions of this agreement (the “Routing Agreement”) and any applicable rules and interpretations of Exchange Rules. Whereas BATS Trading provides certain order routing services for Exchange, and User desires to use the order routing facilities of Exchange, for good and valuable consideration, User and BATS Trading agree as follows:

1. Routing Services. BATS Trading, a wholly owned subsidiary of BATS Global Markets, Inc., agrees to act as agent for User for routing orders into Exchange to the applicable market centers or broker-dealers for execution, whenever such routing is at User’s request, and is permitted in accordance with Exchange Rules. User understands and agrees that orders executed on its behalf shall at times be subject to the terms and conditions of Exchange Rules.

BATS Trading also entered into separate agreements with third- party routing companies, such as Bank of America, Merrill Lynch, Citi and affiliates of Citi, Morgan Stanley, Credit Suisse, and Lime Brokerage, under which these companies routed customers’ orders to external markets on behalf of BATS Trading. BATS Trading, Inc., paid 10

the transaction fees, connectivity fees, and membership fees charged by the external exchanges.

D. Market Makers

The Exchange Rules allowed members to register as market makers in one or more securities traded on the Exchanges. Market makers provided liquidity to the Exchanges by continuously submitting both bids and offers for one or more securities to the Exchanges’ order books during regular trading hours.

IV. Overview of Electronic Trading Platforms

Historically, securities exchanges operated physical locations where stocks were bought and sold, known as trading floors. On these trading floors brokers and dealers physically found each other in order to make trades. Employees of the securities exchanges provided a variety of services to customers to support their trading, such as recording information about trades and helping brokers on the trading floor communicate with their business teams.

Beginning in the late 1990s and early 2000s the traditional model of in-person trading at a single physical location was replaced by that of computerized trading. By 2004 the volume of electronic trading exceeded that of in-person trading.

In an electronic market, buy and sell orders are matched with the use of technology, normally without any human intervention by the market’s operator. Electronic trading platforms allow buy and sell orders to be matched according to a variety of strategies and trades to be executed at high speeds.

The operators of trading venues can use electronic trading platforms in a variety of ways beyond making them available for their members to trade. Operators of trading venues can use electronic trading platforms to operate their markets, including to choose what instruments (e.g., equities, commodities, and options) can be traded on their markets; to choose what order types their markets will accept; to determine who can submit orders to their markets; to cancel erroneous trades; to control whether their markets are open or shut down; to modify the matching engine software so that the matching logic implements the rules of their markets; to electronically disseminate market data to customers; and to receive real-time market information necessary for order execution. 11

V. Operation of the Exchanges

Petitioner’s Exchanges matched the orders of buyers and sellers, functioned as sources of liquidity to petitioner’s customers, and provided customers with fair and orderly places to trade. Petitioner’s customers submitted orders to the Exchanges, and petitioner provided matching and trade execution services.

During the years in issue the Exchanges’ hours of operation were 8 a.m. to 5 p.m. ET Monday through Friday, except for trading holidays. Orders were rejected if they were received outside the hours of operation. Those orders remaining after hours were canceled automatically.

The number of trades executed on BZX was 951,452,396 in 2011, 747,146,823 in 2012, and 681,854,332 in 2013. The number of trades executed on BYX was 266,234,530 in 2011, 292,853,247 in 2012, and 184,728,242 in 2013. These figures do not include executions of trades of fewer than 100 shares, referred to as “odd lot” trades.

Petitioner maintained two customer support departments, the Trade Desk and the Network Operations Center. The Network Operations Center focused on network operations, including customer connectivity and connectivity troubleshooting, and provided secondary support to the Trade Desk. The Trade Desk communicated with customers about the behavior of order types, provided simple connectivity troubleshooting support, coordinated market data requests, informed customers of system updates, assisted with logical port configuration, and certified order entry systems. The Trade Desk could also cancel customer orders. During the years in issue the Trade Desk received approximately 50 to 100 emails and 20 to 40 telephone calls a day from customers requiring assistance.

A. Trading Software

Petitioner developed software that was used in effecting the trading of securities and options on the Exchanges. The Exchanges did not operate solely through the use of petitioner’s trading software but also incorporated third-party software, such as market surveillance software licensed from SMARTS. In developing its trading software, petitioner used Linux operating system software and other open-source software, which petitioner did not develop. Customer orders could not have been executed without this third-party software. 12

All software requires hardware to run. Online software hosted on the internet commonly uses interconnected software modules operating on interconnected computer hardware. Consistent with this model, petitioner’s trading software was installed on interconnected computer servers in a data center in New Jersey that petitioner leased from a third party. Petitioner also maintained a backup data center for disaster recovery purposes.

Petitioner’s computers in the data centers were interconnected to each other and to networking devices such as routers and switches. A computer network is two or more computers that are linked together to allow information sharing, resource sharing, or electronic communication. Petitioner purchased all the hardware used in its system from outside vendors and did not develop the operating system software used on the computers in its network.

To trade on the Exchanges, exchange members needed both “physical” connectivity and “logical” connectivity to petitioner’s system. Customers established physical connectivity by placing their own computer hardware in petitioner’s data center and using a cable to connect their computer hardware to petitioner’s computer hardware. For part of the years in issue, petitioner charged customers a monthly physical connection fee for this wired connection.

Customers established logical connectivity by sending specially formatted electronic messages from order management software on their computers to logical ports in petitioner’s system. A “logical port,” as used in the computing industry, means a combination of a specific Internet Protocol (IP) address of a server and a Transmission Control Protocol (TCP) port, a unique number used to identify a location where data is to be sent. A TCP/IP port is not application software. Together, an IP address and a TCP port number allow a connection to be established between the application software on the computer of the person sending data and a particular instance of the target application software on another computer system.

Order management software was the means by which customers were able to connect with the Exchanges. Petitioner did not develop the order management software that customers used to establish and maintain the logical connection. Customers paid petitioner a monthly logical port fee in relation to this connection. 13

Petitioner’s trading software was not downloaded to customers’ computers or transferred to the random-access memory in customers’ computers. Customers did not enter into license agreements with petitioner. Petitioner did not make copies of any portion of its trading software commercially available to third parties or offer it on a tangible medium or as a hosted arrangement for customers operating an electronic market. Petitioner’s customers were unable to use any of the BATS trading software to operate their own exchange or similar market.

Petitioner’s trading software comprised a variety of software applications, including the following: (1) the order handler, (2) the matching engine, (3) the routing engine, and (4) Multicast PITCH feed servers. Multiple instances of these applications ran on petitioner’s computers at one time. The order handler received customers’ orders, validated orders, accepted or rejected the orders, and upon acceptance of an order converted the order to a proprietary format before relaying the order to the appropriate matching engine.

Customers were limited in their interactions with petitioner’s trading system. They could submit new orders, send requests to modify existing orders or cancel orders resting on the order book, and receive messages regarding the status of their orders. Petitioner also provided customers access, at no charge, to a web portal on which they could adjust the default settings of the order handler software. For example, customers could restrict their ability to submit certain types of orders or set maximum per-order limits. Customers could also select the order handling option of “display price sliding,” through which the displayed price of their orders would be adjusted according to the NBBO, allowing them to obtain a better price on purchase or sale of the security. The order handler applications generated electronic messages that were sent back to customers to inform them of the status of their orders.

Customers sent orders to the order handler using either the Financial Information Exchange (FIX) protocol, with specific modifications by BATS, or petitioner’s proprietary protocol, the binary order entry (BOE) protocol. Instances of the order handler application were programmed to use either the FIX protocol or the BOE protocol. Each instance of the FIX order handler application was programmed to receive up to 5,000 electronic messages per second. Instances of the BOE order handler application were also generally subject to the same restriction. The purpose of these limits was to protect the matching engine from destabilizing because of excessive use. The BOE order handler application also had bulk quoting capabilities for trading on 14

BATS Options, allowing users to send an increased number of orders per second.

The matching engine matched customers’ buy-side and sell-side orders. Customers did not match their own orders. As provided by U.S. securities law, the Exchanges were responsible for bringing together customer orders. See 17 C.F.R. § 240.3b-16(a)(1).

The matching engine applied a time stamp to each order recording the time at which the order arrived in the matching engine or was last modified by the user. In general orders were continuously and automatically matched pursuant to price/time priority, under which priority was given to the best-priced orders in the order in which they arrived on the order book. The best-priced orders were determined using market data about the NBBO from external markets. If the matching engine could not match an order with those resting on the relevant exchange’s relevant order book, it had the functionality to cancel the order or to send the order to the routing engine to be routed to another trading venue.

The routing engine routed a customer’s orders, according to the customer’s instructions, to one or more external markets, such as the New York Stock Exchange or NASDAQ, for potential execution. The routing engine could send an order to multiple external markets at virtually the same time by splitting it into smaller pieces, called child orders. The routing engine contained a software process that converted customer’s orders into a form that would be accepted by the external markets.

The multicast PITCH feed server provided customers with a data feed of orders and executions on the Exchanges. The multicast PITCH server would read the outputs of the matching engine and send anonymized data about order executions and orders displayed on the order book of the relevant exchange to customers. To receive market data from the multicast PITCH server, customers needed to obtain and connect to a PITCH port or a multicast PITCH spin server port offered by petitioner. Petitioner provided some data feeds to customers for free but charged fees for others. Customers did not have to be members of the Exchanges to receive market data. 15

B. The Fees

Petitioner published fee schedules that governed the payments required of petitioner’s customers. The fee schedules did not include the word “software.”

Petitioner claimed as DPGR the receipts from the following three categories of fees it charged its customers: logical port fees, routing fees, and transaction fees. The following table displays petitioner’s receipts from logical port fees, routing fees, and transaction fees during each of the years in issue:

Item 2011 2012 2013 Logical port fees $18,485,900 $25,879,850 $31,640,000 Routing fees 76,882,265 57,551,699 48,885,718 Transaction fees 590,490,229 515,179,765 494,944,299 Total $685,858,394 $598,611,314 $575,470,017

1. Logical Port Fees

Customers paid fixed monthly fees for logical connectivity to certain ports, referred to in petitioner’s fee schedules as “logical ports” (described by petitioner as “FIX ports” and “BOE ports”). On its Forms S–1, Registration Statement Under the Securities Act of 1933, filed with the SEC, petitioner stated that these logical port fees represented fees paid for connectivity to its markets.

Each logical port was configured by petitioner to be able to handle a certain number of orders up to 5,000 messages per second. The messages customers could submit were new orders, requests to modify existing orders, and requests to cancel orders resting on the order book. If customers wanted to submit more than 5,000 messages per second or to send more than one order in parallel, they could pay to connect to more than one logical FIX port or BOE port, as needed for their order flow. Customers paid the same flat monthly fee for connectivity to each of these ports regardless of whether they submitted zero orders or the maximum number of orders per second.

Petitioner also offered ports with bulk quoting capabilities, which imposed no limit on the number of messages submitted per second. 16

These ports were specific to BATS Options and carried a higher fee than the logical ports with limits on the number of messages sent per second.

2. Routing Fees

Petitioner charged routing fees to customers when orders that had been routed to other exchanges or trading venues were executed. Petitioner charged a routing fee only when there was an execution on an external market. When customers made an order, they specified whether the order should be filled on the Exchanges or routed to other exchanges, such as the New York Stock Exchange or dark pools. Dark pools are marketplaces that allow their users to place orders without publicly displaying the size and price of their orders to other participants in the dark pool.

Routing fees were charged to customers using the Exchanges according to the number of shares or option contracts routed to another exchange and the routing strategy used. The fee per share or option contract executed varied with the strategy the customer selected.

Customers were able to select from a variety of strategies for how their orders would be routed to external markets. For example, customers could choose to have their orders routed only to particular types of marketplaces, such as only to dark pools. Customers could also select strategies that prioritized factors such as price or likelihood of execution.

3. Transaction Fees

The primary source of petitioner’s revenues was its transaction fees. When a customer’s order was executed, the customer was either charged a transaction fee or issued a rebate. Petitioner referred to the transaction fees as “Fees for Accessing Liquidity” or “Liquidity Fees” on the fee schedules for BZX and BYX, respectively. The rebates for customers on the opposite side of these executions were referred to as “Liquidity Rebates” or “Rebates for Accessing Liquidity” on BZX and BYX, respectively. Petitioner’s fee schedules provided that petitioner charged a customer a transaction fee or issued a customer a rebate for each share executed that, depending on the exchange, added liquidity to or removed liquidity from the order book.

Liquidity refers to the ability of market participants to buy and sell securities. Generally, the more orders available in a market, the greater the liquidity. In the context of petitioner’s Exchanges, liquidity 17

referred to the number and price range of orders resting on the Exchanges’ order books that were available to be matched with other orders. Petitioner derived liquidity from orders to buy or sell that customers submitted to the Exchanges electronically. Petitioner offered rebates as an incentive to attract market participants and liquidity to the Exchanges.

Whether a customer was charged a fee or issued a rebate depended on which of the Exchanges the customer was trading on and whether the customer’s order was immediately executable when entered. Orders that were not immediately executable when entered were posted on the order book, referred to as adding liquidity. Orders that were immediately executable when entered were referred to as taking, or removing, liquidity. Petitioner generated revenue from the difference between the fees charged to customers and the rebates issued to customers. The following table displays the transaction fees petitioner received and the rebates petitioner paid customers during each of the years in issue:

Item 2011 2012 2013 Transaction fees $695,357,000 $645,310,000 $612,806,000 Rebates 566,103,000 508,169,000 474,688,000

BZX and BATS Options issued rebates for adding liquidity and charged fees for taking liquidity, referred to as a “maker-taker” pricing model. The maker-taker pricing model used by BZX was designed to incentivize market makers to provide liquidity on a continuous basis. Besides the rebate for adding liquidity, market makers were eligible to receive an additional daily rebate on BZX if they satisfied a daily quoting requirement.

BYX charged fees for adding liquidity and issued rebates for removing liquidity, referred to as a “taker-maker” pricing model. Petitioner issued rebates as a financial incentive for customers to prioritize BYX over other markets for their liquidity removal orders.

The price customers were charged per share varied with the type of order the customer submitted. A wide range of order types was available to customers, including market orders, limit orders, reserve orders, discretionary orders, peg orders, and hidden orders. Hidden orders allowed a customer to hide all or a portion of its order from display in market data and on the order book. Petitioner charged 18

different prices for hidden orders compared to orders that were displayed. On BYX petitioner charged higher prices for orders that were subject to display price sliding.

C. Latency

Latency is the time it takes to accept and process orders on an exchange and then to send back the resulting acknowledgment to the customer. A system’s latency is affected by a variety of sources, including hardware processing capabilities, cabling, network equipment, and the manner in which the hardware components are paired with the software.

Petitioner offered customers ultralow latency through its trading system, allowing customers to quickly place, modify, or cancel orders on the Exchanges. Low latency gives customers greater control over their orders and allows them to respond more rapidly to changing market conditions and mitigate trade execution risk. The low latency petitioner offered was important to many of its customers, particularly to those that were market makers. Petitioner achieved low latency through both its software and its hardware.

D. SEC Form 19b–4 Filings

The securities laws required petitioner to file copies of any proposed changes to its Exchange Rules with the SEC, accompanied by an explanation of the basis and purpose of the proposed changes. See 15 U.S.C. § 78s(b)(1). Petitioner filed multiple Forms 19b–4 during the years in issue to submit these proposed rule changes.

On its Forms 19b–4 petitioner described the logical port fees as fees for logical ports, which petitioner stated were “commonly referred to as TCP/IP port[s].” Petitioner also referred to the logical port fees as fees for connectivity. The routing fees were described as fees for executions of orders routed to external markets using petitioner’s routing services. The transaction fees were described as fees for executions that removed liquidity from the BZX order book or added liquidity to the BYX order book. Petitioner did not use the word “software” to describe the Fees.

VI. Commercially Available Trading Software

During the years in issue multiple vendors (collectively, third- party vendors) made customizable electronic trading platforms 19

commercially available to customers. Cinnober Financial Technology AB (Cinnober) offered the TRADExpress Trading System; NYSE Technologies, Inc. (NYSE Technologies), a subsidiary of NYSE Euronext, offered the Universal Trading Platform (UTP); and Millennium Information Technologies (Pvt) Ltd. (MillenniumIT) offered the Millennium Exchange.

To operate an electronic market as a business using the commercially available trading platforms, customers receiving such platforms from the third-party vendors needed to launch their own electronic market, comply with any relevant regulatory requirements, admit members to be eligible to transact on the electronic market, and establish connectivity with users so they could submit orders to the market and receive order status updates and market data. The third- party vendors’ customers were able to set or change user permissions and to determine who would be able to submit orders to their markets.

The third-party vendors offered customers licenses of their trading software, whereby they installed their trading software onto customers’ hardware. MillenniumIT’s customers received the Millennium Exchange software on their own servers at their respective data centers, pursuant to a Licensing and Maintenance Agreement, and also received that software affixed to a tangible medium. NYSE Euronext offered licenses of UTP whereby the UTP software would be installed on the customer’s hardware. Cinnober offered its TRADExpress Trading System to customers pursuant to a software license agreement. Cinnober and NYSE Technologies also offered “hosted” arrangements, whereby they installed the TRADExpress Trading System software and the UTP software, respectively, onto their own hardware and managed the system on behalf of their customers. Customers of Cinnober and NYSE Technologies did not receive rights to make copies of the trading software.

VII. Intuit Inc.’s TurboTax Software

Intuit Consumer Group, Inc., was a subsidiary of Intuit Inc. during the years in issue. Intuit Consumer Group, Inc. (Intuit), offered customers TurboTax tax return preparation software (TurboTax) on CD, by download over the internet, and for use online over the internet. Intuit had a business model of providing TurboTax software for a fee so that customers could prepare their own tax returns. 20

The online use of TurboTax was described in Intuit’s Forms 10–K for the years in issue as “hosted services” or “software as a service.” During the years in issue customers using TurboTax software online agreed to a terms of service agreement, which incorporated by reference product and payment terms from TurboTax’s website. Customers were unable to modify the software, change where it ran, configure it, or exercise administrator privileges such as installing or removing the software.

VIII. Federal Tax Returns

On its originally filed federal income tax returns petitioner claimed deductions under section 199 of $2,644,895, $3,769,767, and $4,074,241 for 2011, 2012, and 2013, respectively. Petitioner attached to its returns Forms 8903, Domestic Production Activities Deduction, and reported DPGR of $683,205,964, $593,695,917, and $571,054,106 for 2011, 2012, and 2013, respectively. Petitioner initially included in its reported DPGR the gross receipts from certain physical port fees and logical port fees for market data ports. Petitioner has since conceded that these amounts were not allowable as DPGR and has revised its claimed DPGR to $677,131,949, $584,942,070, and $559,317,821 for 2011, 2012, and 2013, respectively.

OPINION

We must decide whether petitioner’s gross receipts from the Fees are DPGR. To be DPGR the Fees must satisfy the requirements of Treasury Regulation § 1.199-3(i)(6)(iii)(B): first, that they were derived from providing customers access to computer software for the customers’ direct use while connected to the internet or any other public or private communications network, id. subdiv. (iii); and second, that a third party derived gross receipts from the lease, rental, license, sale, exchange, or other disposition of substantially identical software, id. subdiv. (iii)(B). The parties dispute whether petitioner met the threshold requirements of subdivision (iii) and whether petitioner met the further requirements of subdivision (iii)(B).

Respondent determined that none of petitioner’s gross receipts from the Fees were DPGR. Generally, the Commissioner’s determinations are presumed correct, and the taxpayer bears the burden of proving the Commissioner’s determinations are erroneous. Rule 142(a); Welch v. Helvering, 290 U.S. 111, 115 (1933). The burden of proof may shift to the Commissioner if the taxpayer establishes that 21

he or she complied with the requirements of section 7491(a) to substantiate items, to maintain required records, and to cooperate fully with the Commissioner’s reasonable requests. The record allows us to decide this case without regard to which party bears the burden of proof. See Gibson & Assocs., Inc. v. Commissioner, 136 T.C. 195, 221 (2011).

I. Section 199 Deduction

Congress enacted section 199 as part of the American Jobs Creation Act of 2004, Pub. L. No. 108-357, § 102(a), 118 Stat. 1418, 1424, to provide a tax deduction for certain domestic production activities. Section 199 was intended to stimulate job creation in the United States and strengthen the economy by reducing the tax burden on domestic manufacturers. See ADVO, Inc. & Subs. v. Commissioner, 141 T.C. 298, 311–12 (2013) (citing Gibson & Assocs., Inc., 136 T.C. at 223). Section 199 was repealed for tax years beginning after December 31, 2017. Tax Cuts and Jobs Act of 2017, Pub. L. No. 115-97, § 13305(a), (c), 131 Stat. 2054, 2126.

As in effect during the years in issue, section 199(a) allows a deduction equal to 9% of the lesser of (1) the qualified production activities income (QPAI) of the taxpayer for the tax year, or (2) taxable income (determined without regard to section 199) for the tax year. The amount of the deduction is limited to 50% of the wages of the taxpayer reported on Form W–2, Wage and Tax Statement, for the taxable year that are properly allocable to DPGR. § 199(b). QPAI for any taxable year is an amount equal to the excess, if any, of (A) the taxpayer’s DPGR for such taxable year, over (B) the sum of (i) the cost of goods sold allocable to such receipts and (ii) other expenses, losses, or deductions (other than the deduction under section 199) that are properly allocable to such receipts. § 199(c)(1).

DPGR includes gross receipts derived from any lease, rental, license, sale, exchange, or other disposition of qualifying production property (QPP) that was manufactured, produced, grown, or extracted (MPGE) by the taxpayer in whole or in significant part within the United States. § 199(c)(4)(A)(i)(I). The regulations specify that the term “derived from the lease, rental, license, sale, exchange, or other disposition” (collectively, disposition) is limited to the gross receipts directly derived from the disposition of QPP and note that applicable federal income tax principles apply to determine whether a transaction is a lease, rental, license, sale, exchange or other disposition, a service, or some combination thereof. Treas. Reg. § 1.199-3(i)(1)(i). 22

QPP includes any computer software. § 199(c)(5)(B). The regulations define computer software as “any program or routine or any sequence of machine-readable code that is designed to cause a computer to perform a desired function or set of functions, and the documentation required to describe and maintain that program or routine.” Treas. Reg. § 1.199-3(j)(3)(i).

The definition of DPGR specifically does not include gross receipts derived from services; however, there is an exception for gross receipts derived from engineering or architectural services performed in the United States. § 199(c)(4)(A)(iii). Gross receipts from construction performed in the United States are also included. § 199(c)(4)(A)(ii). The regulations clarify that except as otherwise provided, gross receipts derived from the performance of services do not qualify as DPGR. Treas. Reg. § 1.199-3(i)(4)(i)(A). In the case of an embedded service, that is, a service for which the price, in the normal course of the taxpayer’s business, is not separately stated from the amount charged for the lease, rental, license, sale, exchange, or other disposition of QPP, DPGR includes only the gross receipts derived from the disposition of QPP and not any receipts attributable to the embedded service. Id.

A. Computer Software

DPGR includes gross receipts derived from the lease, rental, license, sale, exchange, or other disposition of computer software MPGE by the taxpayer in whole or in significant part within the United States. Id. subpara. (6)(i). Such gross receipts qualify as DPGR even if the customer provides the computer software to its employees or others over the internet. Id. Consistent with the general treatment of services under section 199, gross receipts derived from customer and technical support, telephone and other telecommunication services, online services (such as internet access services, online banking services, providing access to online electronic books, newspapers, and journals), and other similar services do not constitute gross receipts derived from a lease, rental, license, sale, exchange, or other disposition of computer software. Treas. Reg. § 1.199-3(i)(6)(ii).

The regulations provide narrow exceptions to the general rule excluding online services from DPGR. Notwithstanding Treasury Regulation § 1.199-3(i)(6)(ii), if a taxpayer derives gross receipts from providing customers access to computer software MPGE in whole or in significant part by the taxpayer within the United States for the customers’ direct use while connected to the internet or any other public 23

or private communications network (online software), such gross receipts will be treated as derived from the disposition of computer software only if Treasury Regulation § 1.199-3(i)(6)(iii)(A) or (B) is met. Id. subdiv. (iii).

Treasury Regulation § 1.199-3(i)(6)(iii)(A) requires that the taxpayer also derive, on a regular and ongoing basis in the taxpayer’s business, gross receipts from the disposition to customers of computer software that has only minor or immaterial differences from the online software in a tangible medium or by download. We refer to subdivision (iii)(A) as the self-comparable exception. Cf., e.g., I.R.S. Chief Couns. Adv. Mem. 201603028 (Jan. 15, 2016). Petitioner does not assert that it meets the requirements of the self-comparable exception.

Treasury Regulation § 1.199-3(i)(6)(iii)(B) requires that another person derive, on a regular and ongoing basis in its business, gross receipts from the disposition in a tangible medium or by download of substantially identical software (as compared to the taxpayer’s online software) to its customers. We refer to subdivision (iii)(B) as the third- party comparable exception. Cf., e.g., I.R.S. Chief Couns. Adv. Mem. 201603028. For purposes of the third-party comparable exception substantially identical software is computer software that (1) from a customer’s perspective has the same functional result as the taxpayer’s online software and (2) has a significant overlap of features or purpose with the taxpayer’s online software. Treas. Reg. § 1.199-3(i)(6)(iv)(A).

B. Background on the Exceptions

On January 19, 2005, the Department of the Treasury (Treasury) issued I.R.S. Notice 2005-14, 2005-1 C.B. 498, to provide interim guidance on section 199. The notice stated: “Except as provided in the safe harbor [for embedded services], gross receipts derived by a taxpayer from software that is merely offered for use to customers online for a fee are not DPGR.” Id., 2005-1 C.B. at 508. This general rule, that the provision of online software constituted a service, was also reflected in the proposed regulations published November 4, 2005, which stated that “the use of online computer software does not rise to the level of a lease, rental, license, sale, exchange, or other disposition as required under section 199 but is instead a service.” REG-105847-05, 70 Fed. Reg. 67,220, 67,226; see also id. at 67,250. Treasury requested comments “concerning whether gross receipts derived from the provision of certain types of online software should qualify under section 199 as being derived from a lease, rental, license, sale, exchange, or other disposition 24

of the software and, if so, how to distinguish between such types of online software.” Id. at 67,239.

On June 12, 2006, Treasury issued temporary regulations regarding section 199. The supplementary information to the temporary regulations noted that on July 21, 2005, the Chairman and the Ranking Member of the Senate Finance Committee and the Chairman of the House Ways and Means Committee sent a letter to Treasury regarding the treatment of online access to computer software. T.D. 9262, 2006-1 C.B. 1040, 1040–41. The letter requested that Treasury consider whether the treatment of computer software accessed online should be similar to the treatment of computer software distributed by other means, such as by physical delivery or delivery via internet download. Id., 2006-1 C.B. at 1041. The letter also noted that “gross receipts from the provision of services are not treated as DPGR, regardless of the fact that computer software may be used to facilitate such service transactions.” Id.

The supplementary information to the temporary regulations also summarized comments regarding the treatment of online software. Comments suggested that a customer’s use of computer software is tantamount to a license of the computer software. Id. Other commentators suggested that “other disposition” in section 199(c)(4)(A) is broad enough to include the provision of computer software for online use. Id. These comments were not incorporated into the temporary regulations. Id. Instead, the temporary regulations introduced two exceptions to the overall exclusion of gross receipts derived from online software from DPGR.

The supplementary information noted that these exceptions, the self-comparable exception and the third-party comparable exception, were added “as a matter of administrative convenience” to provide “two exceptions under which gross receipts derived by a taxpayer from providing computer software to customers for the customers’ direct use while connected to the Internet will be treated as being derived from the lease, rental, license, sale, exchange, or other disposition of such computer software.” Id.

On April 16, 2007, Treasury promulgated final regulations under section 199. The supplementary information to the final regulations reiterates first the general rule that gross receipts derived from online services are excluded from DPGR, and second, the two exceptions from 25

this rule, under which gross receipts derived from online software are treated as DPGR. T.D. 9317, 2007-1 C.B. 957, 958.

II. Fees

In order for the Fees to be treated as DPGR, the requirements of Treasury Regulation § 1.199-3(i)(6)(iii) must be met. Petitioner must first show that the Fees were derived from providing customers access to computer software MPGE in whole or in significant part by petitioner within the United States for customers’ direct use while connected to the internet or any other public or private communications network. See id. If this first requirement is met, petitioner must show that either the self- comparable exception or the third-party comparable exception is met. See id.

Petitioner contends that it made a disposition of computer software for its customers’ direct use. We disagree. Petitioner did not provide its customers direct access to its software as defined in the Code and the regulations.

A. Logical Port Fees

Petitioner claimed its logical port fees as DPGR because it contends that the logical port fees were derived from providing customers access to the order handler component of its trading software for the customers’ direct use. 1 Access to logical ports provided customers with access to petitioner’s private communications network. In other words, the logical ports provided connectivity.

The logical ports validated customers’ orders and forwarded them to the matching engine. Petitioner charged the logical port fees at a flat monthly rate for each FIX or BOE port assigned to a customer. The fee for each logical port did not increase or decrease according to whether a customer submitted, modified, or canceled orders.

Logical ports enabled customers to interact with the Exchanges. The connection through the logical ports took the place of going to an exchange in person. This interaction is similar to internet access services that enable users to browse the world wide web, to transfer files, and to access e-mail. See Nat’l Cable & Telecomms. Ass’n v. Brand X Internet Servs., 545 U.S. 967, 987 (2005). Gross receipts from internet

1 After concessions, the only logical port fees petitioner claims as DPGR are

those charged for logical connectivity to petitioner’s system. 26

access services do not constitute gross receipts derived from a lease, rental, license, sale, exchange, or other disposition of software. See Treas. Reg. § 1.199-3(i)(6)(ii). Connection to the logical ports is akin to internet access rather than direct use as described in Treasury Regulation § 1.199-3(i)(6)(iii)(B).

The logical port fees are payments for access to petitioner’s private communications network. Accordingly, the logical port fees are not DPGR. The applicable regulations provide examples that contrast what is DPGR and is not DPGR. Example 3 addresses N, a provider of telephone services, voicemail services, and email services. Treas. Reg. § 1.199-3(i)(6)(v) (example 3). N produces computer software in the United States that runs the above-described services. Id. This example concludes that N’s gross receipts derived from the telephone and other communication services are non-DPGR because Treasury Regulation § 1.199-3(i)(6)(ii) excludes gross receipts derived from telephone and related communication services from gross receipts derived from a disposition of computer software. Id. Petitioner’s logical port fees are analogous to Example 3. Both fees are for services that provide the customer with a connection.

B. Routing Fees

Petitioner claimed its routing fees as DPGR. Petitioner contends that the routing fees were derived from providing customers access to the routing-related functionality of its trading software for the customers’ direct use.

The routing fees were charged only upon the execution of a customer’s order on an external market. Customers could select different routing strategies for how their orders would be routed to different markets. The price of the fee per share or option contract executed varied with the strategy the customer selected.

Pursuant to petitioner’s securities routing agreement, BATS Trading, Inc., routed orders to external exchanges as the customers’ agent. Sometimes a third party, such as Morgan Stanley, routed customers’ orders on behalf of BATS Trading, Inc. In routing customers’ orders, BATS Trading, Inc., paid transaction, connectivity, and membership fees charged by the external exchanges. Petitioner asserts that the involvement of BATS Trading, Inc., in routing customers’ orders was a legal formality because of the applicable regulatory scheme. 27

Petitioner further asserts that customers should really be considered to route their own orders.

Customers did not use petitioner’s software to route their orders. They could only submit orders with instructions as to routing strategy. BATS Trading, Inc., pursuant to the securities routing agreement, acted as the customers’ agent for the purpose of providing these routing services. The varying prices customers paid for routing strategies reflected the different services petitioner provided, such as routing orders to particular types of external markets. Customers paid for different services, not different uses of the trading software.

The routing fees were charged for the routing and trade execution services performed for customers. They were not derived from customers’ access to software for their direct use.

C. Transaction Fees

Petitioner claimed its transaction fees as DPGR. Petitioner contends that the transaction fees were derived from providing customers access to the matching-related functionality of its trading software for the customers’ direct use.

The transaction fees were charged only upon the execution of a customer’s order. A customer’s trade could not be executed solely by the customer’s submitting a bid or offer to the Exchanges; trade executions required counterparties. The rebates petitioner offered, which on average were equal to 79% of the transaction fees petitioner received, were a core part of petitioner’s business strategy to attract those counterparties to the Exchanges.

Petitioner’s transaction fees were not charged to customers according to the extent to which they made use of the Exchanges. Not every submitted order was executed, and therefore not every submitted order triggered a transaction fee. Not every customer whose order was executed paid a transaction fee, because one party to each trade was issued a rebate. A customer who was charged a fee took the same actions to submit an order as the customer who was issued a rebate or the customer whose submitted order was never executed. The transaction fees were charged to customers according to how much they accessed or removed liquidity, depending on the relevant exchange, as reflected in petitioner’s fee schedules, where the transaction fees were referred to as “Fees for Accessing Liquidity” or “Liquidity Fees.” They thus reflected the trade execution services petitioner provided. 28

The varying prices petitioner charged customers for different order types also demonstrate that the transaction fees were derived from services. The different prices of the transaction fees reflected the different services petitioner performed for customers, such as hiding their orders from being displayed in market data or adjusting the order prices using display price sliding. Customers paid for different services, not different uses of the trading software.

The regulations provide an analogous example of a company that uses computer software to provide online services to customers. Example 2 describes M, an internet auction company that produces computer software within the United States that enables its customers to participate in internet auctions for a fee. Treas. Reg. § 1.199-3(i)(6)(v) (example 2). The example does not elaborate on how M’s auction software enabled customers to participate in internet auctions or how M’s customers participated in internet auctions; it focuses only on the fact that M’s activities constituted the provision of online services. The example concludes that M’s gross receipts derived from the internet auction services are non-DPGR because Treasury Regulation § 1.199- 3(i)(6)(ii) excludes gross receipts derived from online services from gross receipts derived from a disposition of computer software.

Petitioner’s transaction fees are analogous to Example 2. Both petitioner and M, the company in the example, charged their customers fees for participation in electronic markets and facilitated this service with computer software. Petitioner’s provision of trade execution services was an online service within the meaning of Treasury Regulation § 1.199-3(i)(6)(ii). Petitioner’s customers did not directly use its software within the meaning of Treasury Regulation § 1.199- 3(i)(6)(iii).

D. Conclusion to the Fees

Petitioner is an operator of securities exchanges. The fact that the Exchanges use software to operate does not convert petitioner’s trade execution services into the provision of software for customers’ direct use.

Petitioner further contends that the regulatory requirements of access and direct use should be interpreted with reference to TurboTax, Intuit’s online tax preparation software. Petitioner points to regulatory examples showing that providing customers access to online tax preparation software constitutes access and direct use for purposes of 29

the regulation. See Treas. Reg. § 1.199-3(i)(6)(v) (examples 4 and 5). Examples 4 and 5 illustrate the self-comparable exception and the third- party comparable exception, respectively, using the example of a company that derives gross receipts from providing customers access to online tax preparation software for customers’ direct use while connected to the internet. Id. Petitioner argues that the way Intuit’s customers interacted with TurboTax was not meaningfully different from how its customers interacted with the trading software. We disagree with petitioner that its trading software can be compared to TurboTax.

The developers of tax preparation software have a business model that consists of supplying online software for a fee so customers can prepare their tax returns. Petitioner, in contrast, used its trading software as part of its business to provide services to its customers. Unlike the tax preparation company in the examples, petitioner did not offer customers its trading software on CD or by download over the internet, nor has it shown that third parties offered customers substantially identical software to its trading software. Petitioner is more like the companies described in regulatory Examples 1 and 2, which produce computer software that they use as part of their business. See id. (examples 1 and 2). In Example 1, a bank produces computer software that enables its customers to receive online services for a fee. In Example 2, an internet auction company produces computer software that enables its customers to participate in internet auctions for a fee. Petitioner and Intuit used their software in different ways in their respective businesses and are not comparable.

Petitioner’s customers could submit orders to the Exchanges, but they could not themselves use the trading software to route or execute their orders. They could only request that petitioner perform these trade execution services. Petitioner’s agreements with its customers show that customers received services, not the use of software, from petitioner. The user agreement characterized customers’ access to the Exchanges for order entry and trade execution as services, not as the direct use of software. Likewise, the securities routing agreement referred to routing services, to be performed by BATS Trading, Inc.

Petitioner repeatedly characterized its Fees as fees for providing trade execution services to customers, not fees for the direct use of software. Further, petitioner’s filings with the SEC did not describe the Fees as fees for customer use of software. Instead, petitioner represented that the logical port fees were for connectivity to its 30

Exchanges, that the routing fees were for the execution of orders routed to external markets using petitioner’s routing services, and that the transaction fees were for adding or removing liquidity. Petitioner also represented to the SEC that the Exchanges, not customers, were responsible for matching and executing orders. See 17 C.F.R. § 240.3b- 16(a)(1). Consistent with petitioner’s representations, the Fees were derived from services, not the direct use of software. See Treas. Reg. § 1.199-3(i)(6)(iii).

III. Third-Party Comparable Exception

We hold that petitioner did not meet the threshold requirements of Treasury Regulation § 1.199-3(i)(6)(iii) with respect to the Fees. In the alternative, we consider whether petitioner met the further requirements of one of the exceptions under subdivision (iii), the self- comparable exception or the third-party comparable exception. In this case petitioner argues only that it meets the requirements of the third- party comparable exception, Treasury Regulation § 1.199-3(i)(6)(iii)(B). Petitioner does not meet those requirements.

For petitioner to qualify for the third-party comparable exception, a third party must derive, on a regular and ongoing basis in its business, gross receipts from the disposition to its customers of software that is substantially identical to petitioner’s online software in a tangible medium or by download. See id. In order to be substantially identical to petitioner’s software for purposes of Treasury Regulation § 1.199- 3(i)(6)(iii)(B), a third-party vendor’s computer software must (1) from a customer’s perspective, have the same functional result as petitioner’s online software and (2) have a significant overlap of features or purpose with petitioner’s online software. See id. subdiv. (iv)(A).

Petitioner contends that respondent’s interpretation of the substantially identical requirement is too narrow. It disputes respondent’s position that for software to be substantially identical, the user of the taxpayer’s software and the immediate purchaser of the third party’s software must use the respective software in the same way. Petitioner’s position is that only the software itself needs to be comparable.

The plain meaning of a regulation governs if the regulation is not ambiguous. Safe Air For Everyone v. EPA, 488 F.3d 1088, 1097 (9th Cir. 2007). A court must consider the text, structure, history, and purpose of a regulation before concluding that it is genuinely ambiguous. Kisor 31

v. Wilkie, 139 S. Ct. 2400, 2415 (2019); see also Amazon.com, Inc. & Subs. v. Commissioner, 934 F.3d 976, 984 (9th Cir. 2019), aff’g 148 T.C. 108 (2017).

Treasury regulations must be interpreted in the context of the statute they are designed to explicate. Bank of New York v. United States, 526 F.2d 1012, 1018 (3d Cir. 1975). Regulations are not an opportunity to amend a statute. United States v. Calamaro, 354 U.S. 351, 359 (1957); Koshland v. Helvering, 298 U.S. 441, 447 (1936). Petitioner’s interpretation of Treasury Regulation § 1.199-3(i)(6)(iii) would expand the definition of DPGR to include gross receipts derived from services as long as online software facilitated or enabled those services.

For its expansive view of the regulation petitioner relies upon the safe harbor for computer software games found in Treasury Regulation § 1.199-3(i)(6)(iv)(B). The safe harbor provides that all computer software games are deemed to be substantially identical for purposes of Treasury Regulation § 1.199-3(i)(6)(iv)(A), which describes the substantially identical software requirement of the third-party comparable exception. Petitioner contends the definition of substantially identical software is broad and consistent with the safe harbor for computer software games. It argues that the safe harbor treats all games as substantially identical even though there are significant differences among games. Petitioner points out that the safe harbor explains that computer software sports games are deemed substantially identical to computer software card games. See id. subdiv. (iv)(B).

We disagree with petitioner that the safe harbor supports a broad interpretation of substantially identical software. The safe harbor is unambiguous. The safe harbor is titled “Safe harbor for computer software games.” It states “all computer software games,” which clearly does not include other types of software, such as trading software. See id.

Treating all computer games as substantially identical software clearly does not mean that other types of software, such as trading software, can be treated as substantially identical software. This Court has traditionally taken the position that our responsibility is to apply the law to the facts of the case before us and not look at how other taxpayers have been treated. Gaughf Props., L.P. v. Commissioner, 139 T.C. 219, 254 (2012) (citing Davis v. Commissioner, 65 T.C. 1014, 1022 32

(1976)), aff’d, 738 F.3d 415 (D.C. Cir. 2013). If all trading software is to be treated as substantially identical software, it should have been included in the safe harbor or the regulation should have provided an additional safe harbor for it. As written, the safe harbor applies only to computer games and has no implications for whether a third-party vendor’s trading software would qualify as substantially identical software.

Respondent’s application of Treasury Regulation § 1.199- 3(i)(6)(iv)(A) is not arbitrary simply because it results in different treatment for different taxpayers. In matters of taxation the selection of subjects of taxation, rates, classes of beneficiaries, and permissible deductions has a large element of arbitrariness. Danly Mach. Corp. v. United States, 492 F.2d 30, 33 (7th Cir. 1974). Congress may give a deduction to all in a narrowly defined class and deny it to those who are distinguishable from the class. Id. The safe harbor unambiguously applies only to computer software games, and respondent reasonably interprets the definition of substantially identical software without reference to the safe harbor.

Petitioner further contends that the requirement that substantially identical software have the same functional result from a customer’s perspective does not demand comparability between the taxpayer’s customers and customers of a third party. It argues that the “customer” referred to in the regulation should be understood to include not just the customers from whom the third-party vendors derived gross receipts, but also the customers of those customers. Petitioner would include as customers the entities that traded on the exchanges run by the third-party vendor’s customers. Respondent contends that a “customer” refers to the third-party vendors’ actual customers, which in this case would be the exchange operators.

We interpret a regulation in the context of the regulatory scheme as a whole. McCarthy v. Bronson, 500 U.S. 136, 139 (1991). Treasury Regulation § 1.199-3(i)(6)(iii)(B) specifically uses the words “to its customers” and this clearly means the customers of the third-party vendor. The “substantially identical software” definition in Treasury Regulation § 1.199-3(i)(6)(iv)(A) uses the words “a customer’s perspective.” Respondent contends this wording means a customer of the third party that provides the comparable software for purposes of the third-party comparable exception. 33

We agree with respondent’s interpretation. Petitioner’s interpretation ignores the context of the definition of substantially identical software. The definition is provided specifically for purposes of Treasury Regulation § 1.199-3(i)(6)(iii)(B). See id. subdiv. (iv)(A). The definition, and its reference to a “customer,” cannot be considered without looking at Treasury Regulation § 1.199-3(i)(6)(iii)(B). The two subdivisions, read together, require that the functional result of a third- party vendor’s software be evaluated from the perspective of an actual customer receiving the commercially available trading software from the third-party vendor, as compared with the perspective of petitioner’s customers.

Petitioner argues that it meets this requirement through the commercially available trading software of the third-party vendors: NYSE Euronext, which offered the UTP; Cinnober, which offered the TRADExpress Trading System; and MillenniumIT, which offered the Millennium Exchange. Customers of the third-party vendors received the commercially available trading software on their own hardware, pursuant to license agreements. They could then use the software to operate electronic markets.

Petitioner’s trading software was also used to operate electronic markets during the years in issue. However, petitioner itself operated the Exchanges. Petitioner’s customers could only submit, cancel, and modify orders to trade securities. Petitioner’s customers did not execute license agreements with petitioner and could not operate their own electronic markets using petitioner’s Exchanges.

Trading securities and operating a securities exchange are two distinct activities and are not the same functional result from a customer’s perspective. Petitioner and the third-party vendors had fundamentally different relationships with their customers with regard to the operation of a securities exchange. For the third-party vendors, there were three steps in the relationship: first, the third-party vendors developed trading software that they licensed to customers; second, customers used the software to run their own exchanges; and third, members of the exchanges (whether the operators of the exchanges or their own customers) participated in trading on the exchanges. Petitioner, on the other hand, skipped this middle step and offered its customers participation in trading on its exchanges.

The regulatory examples, although they do not provide a definition of “functional result” or “features or purpose,” are instructive. 34

In Examples 5 and 6, a third party that provides customers access to a particular type of computer software is stated to offer substantially identical software to a taxpayer that provides customers with the same type of computer software. Treas. Reg. § 1.199-3(i)(6)(v) (examples 5 and 6). The Examples therefore show that a third party’s computer software that its customers use for a particular activity (tax preparation, in Example 5, or payroll management, in Example 6) can be substantially identical software as compared to a taxpayer’s computer software that is used for the same activity.

In Example 7, a third party’s payroll management software is stated not to be substantially identical software as compared to the taxpayer’s inventory computer software. Id. (example 7). The extent of the detail that the Example provides about the two companies is that the taxpayer company’s customers use its software for inventory, and the third party’s customers use its software to manage payrolls. These are two distinct activities.

The third-party vendors’ software is not substantially identical to petitioner’s software within the meaning of Treasury Regulation § 1.199-3(i)(6)(iv)(A), and therefore petitioner does not meet the requirements of the third-party comparable exception. See id. subdiv. (iii)(B).

IV. Conclusion

Petitioner claimed the gross receipts from its Fees as DPGR. All three categories of Fees at issue—transaction fees, routing fees, and logical port fees—were derived from services petitioner performed for customers in the course of operating its Exchanges. The Fees were not derived from providing customers access to computer software for their direct use, and they therefore do not meet the requirements of Treasury Regulation § 1.199-3(i)(6)(iii).

Even if the Fees could meet the requirements of Treasury Regulation § 1.199-3(i)(6)(iii), they do not meet the further requirements of the third-party comparable exception. Petitioner has not demonstrated that a third party derived gross receipts from the disposition to its customers of software that was substantially identical to petitioner’s online software. See id. subdiv. (iii)(B).

Any contentions we have not addressed are irrelevant, moot, or meritless. 35

To reflect the foregoing,

Decision will be entered under Rule 155.