United States Tax Court

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 thirdparty 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 takermaker pricing. See infra Section V.B.3. Transaction Fees. BATS YExchange, 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.3b16(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 thirdparty 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

$685,858,394

$598,611,314

$575,470,017

Total

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, thirdparty 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 thirdparty 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 thirdparty 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 selfcomparable 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.1993(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.1993(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 thirdparty 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.3b16(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 selfcomparable exception or the third-party comparable exception. In this

case petitioner argues only that it meets the requirements of the thirdparty 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.1993(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.1993(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 thirdparty 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.