# United States Tax Court

> Briefs, arguments, decisions, and more.

URL: https://www.frixlaw.com/law-library/documents/agency%3Atax-court%3Af2616401b80d9b85

## Record

- **Collection:** Agency decision
- **Document type:** Agency decision

## Text

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.

---

Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/agency%3Atax-court%3Af2616401b80d9b85. Public record. Not legal advice.