The opinion
USDC SDNY
DOCUMENT
UNITED STATES DISTRICT COURT ELECTRONICALLY FILED
SOUTHERN DISTRICT OF NEW YORK DOC #:
DATE FILED: 10/11/2024
EDMAR FINANCIAL COMPANY,
LLC, ET AL.,
DECISION AND
Plaintiff(s), ORDER
-V- 21-CV-6598 (LAK) (HJR)
CURRENEX, INC., ET AL.,
Defendant(s).
HENRY J. RICARDO, United States Magistrate Judge.
Presently before the Court are Plaintiffs’ motion to compel production of
Currenex’s matching algorithm source code and related documents, ECF No. 132,
and Defendant Currenex, Inc.’s (““Currenex’”) cross-motion to compel Plaintiffs to
produce their foreign exchange (“FX”) trading methodologies and algorithms, ECF
No. 134. For the reasons described below, Plaintiffs’ motion to compel is hereby
GRANTED and Currenex’s cross-motion to compel is hereby DENIED.
I. BACKGROUND
A. Facts
This decision assumes familiarity with the background of this litigation,
which is described in Judge Kaplan’s May 18, 2023 Opinion granting in part and
denying in part Defendants’ motions to dismiss. ECF No. 83. This decision
therefore discusses only those facts most relevant to the current disputes.
Currenex operates an electronic platform for FX transactions. ECF No. 96,
Second Amended Complaint § 4 (“SAC”). These FX transactions take the form of an
exchange of one currency for another at a given price. The most common trades on
the Currenex platform are Euro/U.S. dollar, U.S. dollar/Japanese Yen, and British
pound/U.S. dollar. SAC ¶ 59. To trade on the Currenex platform, market
participants submit bids (the prices at which they are willing to buy) or offers (the
prices at which they are willing to sell). SAC ¶ 4. The platform uses a “matching
logic” that completes trades by matching bids with offers. SAC ¶ 5.
Plaintiffs allege that Currenex and State Street Global Markets
International Limited conspired with certain participants that traded on Currenex’s
FX trading platform—including Goldman, Sachs & Co. LLC, HC Technologies, LLC,
State Street Bank and Trust Company, and other Doe Defendants (the “Trading
Defendants”)—to give those participants secret privileges, including the ability to
complete transactions without entering competitive bids. SAC ¶¶ 11-12.
In particular, Plaintiffs allege that Currenex misrepresented how its trading
platform breaks “ties” between multiple bids or offers at the same price. SAC ¶ 18.
A “tie” occurs when, for example, the number of bids exceeds the number of
matching offers at a given price. When there is such an excess of bids, the matching
logic must decide which of the equal bids are paired with offers, resulting in
consummated trades, and which of the equal bids are not paired with offers, leaving
those bids unfulfilled. In other words, the matching logic decides which equal bids
are successful and which are not.
Plaintiffs allege that Currenex represented that ties between multiple bids or
offers would be broken on a “first in, first out” basis, meaning that an earlier
2
submission would prevail over a later submission at the same price. SAC ¶ 7.
Currenex later represented that it changed its tiebreaking methodology to add a
prioritization of “firm orders” over quotes that were subject to the platform’s “last
look” feature, which allowed bids or offers to be canceled before completion of a
trade. SAC ¶ 9. As relevant to this discovery dispute, Plaintiffs allege that these
representations were false because Currenex actually broke ties by favoring the
Trading Defendants regardless of whether a Trading Defendant’s bid or offer came
in first or was a firm offer. SAC ¶ 11.
Plaintiffs allege that these undisclosed tiebreaking rules harmed them
because they “paid too much when buying, received too little when selling, and
incurred increased execution costs” as a result. SAC ¶ 12. Additionally, Plaintiffs
allege that they lost business and profits they otherwise would have been able to
realize if Currenex had broken ties in accordance with its public representations.
SAC ¶ 13.
B. Pending Discovery Motions
1. Plaintiffs’ July 3, 2024 Motion to Compel
On July 3, 2024, Plaintiffs filed a letter motion to compel Currenex to
produce the source code for its matching algorithm, i.e., the instructions that its
computer system uses to implement the matching algorithm, and certain related
documents. ECF No. 132 (the “July 3 Letter”). Plaintiffs requested production of
3
these materials in Plaintiffs’ Document Request No. 49 (“Request 49”).1 Plaintiffs
contend that these documents are relevant because a central issue in the case is
whether Currenex misrepresented the tiebreaking rules used on its platform, and
those tiebreaking rules are specified in the source code.
As part of the meet-and-confer process, the parties explored alternative ways
to identify Currenex’s tiebreaking rules. Toward that end, Currenex produced a
sample of transactional data said to allow Plaintiffs to determine the matching
algorithm. After analyzing this sample transactional data, however, Plaintiffs
concluded that it was not an acceptable substitute for the source code itself. Not
only was it burdensome to attempt to divine the matching algorithm in this way,
but Plaintiffs concluded that such an exercise was ultimately futile, inter alia, due
to the volume and complexity of this data and the unavailability of data for some
portion of the relevant period. July 3 Letter at 4. Additionally, Plaintiffs expressed
concern that no matter how carefully they tried to reverse-engineer the tiebreaking
algorithm using transactional data, Plaintiffs would always be vulnerable to claims
that they had done so inaccurately, leading to further disputes over what matching
algorithm Currenex actually used. Id. Accordingly, Plaintiffs contend there is no
adequate substitute for the source code itself.
1 Request 49 seeks: “(a) the Source Code; (b) all changes to that Source Code (including all
configuration files, configuration history, version control history, and log files of all priority
changes made on the matching engine); (c) Documents used to request, order, or specify
changes in the operation of the matching and Tiebreaking Rules by and method . . .; and (d)
data dictionaries and instruction manuals that describe the operation and data used by
that Source Code . . . .”
4
2. Defendant Currenex’s July 9, 2024 Response and Cross-
Motion to Compel
On July 9, 2024, Currenex filed a response letter advising that it had already
agreed to produce its source code and that “Plaintiffs’ letter-motion is moot.” ECF
No. 134 (the “July 9 Letter”) at 1. Currenex did not dispute the relevance of either
its source code or the related materials requested by Plaintiffs (e.g., changes to the
source code, documents seeking changes to the tiebreaking rules, data dictionaries
and instruction manuals), nor did Currenex oppose production of these documents
based on burden.
Instead, Currenex’s July 9 Letter cross-moved to compel Plaintiffs to produce
their respective foreign exchange trading methodologies and algorithms.2 Currenex
called for such production through Defendants’ Document Request No. 10 (“Request
10”).3 Currenex argued that it needs this source code to test Plaintiffs’ assertion
that they would have traded differently, i.e., would not have used the Currenex
platform, had they known the allegedly concealed tiebreaking rules. Further,
Currenex claimed that it needs Plaintiffs’ source code “for many of the same
reasons” that Plaintiffs cited in their own motion to compel. July 9 Letter at 4.
2 As discussed further below, Currenex does not dispute that only XTX traded on the
Currenex platform using source code. The Court therefore construes Currenex’s cross-
motion as one to compel the production of XTX’s source code.
3 Request 10 seeks: “Documents and Data, including source code, concerning algorithms or
other methodologies You used in connection with FX Transactions on the Platform or any
other ECN or trading platform, including but not limited to algorithms or methodologies
designed to evaluate, route, and/or place orders and/or to select trading platforms on which
to place orders.”
5
On July 17, 2024, Plaintiffs filed their response to Currenex’s cross-motion.
ECF No. 138 (the “July 17 Letter”). Plaintiffs clarified that Currenex’s cross-motion
applies only to XTX because XTX is the only Plaintiff that uses source code to trade.
July 17 Letter at 1, n.2 (“[t]he other Plaintiffs did not trade using ‘source code.’”). In
order to resist production of its own source code, XTX filed a declaration by its
Global Head of Distribution, Jeremy Smart, explaining that the information
Currenex seeks, including what XTX would have done had it known the actual
tiebreaking rules, is not contained in this source code. ECF No. 139 (the “Smart
Declaration” or “Smart Decl.”). Additionally, the Smart Declaration described the
burden that producing the source code would impose and the high sensitivity of the
source code itself. Finally, Plaintiffs suggested that Currenex could obtain the
information it seeks by alternate, less intrusive means, such as transactional data,
interrogatory responses, deposition testimony, or stipulations regarding the
features of the algorithm. July 17 Letter at 3.
On July 22, 2024, Currenex filed a reply letter in further support of its cross-
motion. ECF No. 140 (the “July 22 Letter”). The July 22 Letter did not dispute that
XTX is the only Plaintiff using source code to trade on the Currenex exchange and
referred only to XTX’s source code. Without directly rebutting any of the factual
statements made in the Smart Declaration about what the XTX source code does
and does not contain, the July 22 Letter argued that this source code is needed to
show how the XTX trading algorithms would have adjusted trading volumes both
across trading platforms and within the Currenex trading platform had Plaintiffs
6
known the alleged secret tiebreaking rules. The July 22 Letter did not take issue
with any of XTX’s factual assertions regarding either the sensitivity of its source
code or the burden of producing it, nor did it address whether Currenex could obtain
the information it seeks by other means.
On July 23, 2024, Plaintiffs filed a sur-reply. ECF No. 141 (the “July 23
Letter”). The July 23 Letter mainly pointed out certain questions that the July 22
Letter failed to address and suggested that Currenex’s relevance arguments had
shifted between its opening letter and its reply letter. Id. at 2.
Pursuant to 28 U.S.C. § 636(b)(1)(A), Judge Kaplan referred this specific non-
dispositive motion to Magistrate Judge Ona T. Wang on July 10, 2024. ECF No.
135. On August 29, 2024, this referral was reassigned to me.
II. DISCUSSION
A. Legal Standards
Rule 26 of the Federal Rules of Civil Procedure provides that “[p]arties may
obtain discovery regarding any nonprivileged matter that is relevant to any party’s
claim or defense and proportional to the needs of the case[.]” Fed. R. Civ. P.
26(b)(1). Information is “relevant” if “(a) it has any tendency to make a fact more or
less probable than it would be without the evidence; and (b) the fact is of
consequence in determining the action.” Fed. R. Evid. 401. Relevant information
“within th[e] scope of discovery need not be admissible in evidence to be
discoverable.” Fed. R. Civ. P. 26(b)(1). Indeed, relevance is an extremely broad
concept for purposes of discovery. Pearlstein v. Blackberry Ltd., 332 F.R.D. 117, 120
7
(S.D.N.Y. 2019). “The party seeking discovery bears the initial burden of proving
the discovery is relevant.” Sheindlin v. Brady, No. 21-cv-01124 (LJL) (SDA), 2021
WL 2075483, at *2 (S.D.N.Y. May 24, 2021).
A court must evaluate whether the benefit of requested discovery is
proportional to the burden of producing it. To assess proportionality, a court
considers “the importance of the issues at stake in the action, the amount in
controversy, the parties’ relative access to relevant information, the parties’
resources, the importance of the discovery in resolving the issues, and whether the
burden or expense of the proposed discovery outweighs the likely benefit.” Fed. R.
Civ. P. 26(b)(1).
“Rule 26 gives a district court broad discretion . . . to impose limitations or
conditions on discovery . . . which extends to granting or denying motions to compel
or for protective orders on just terms.” Coty Inc. v. Cosmopolitan Cosmetics Inc., No.
18-cv-11145 (LTS) (SLC), 2020 WL 3317204, at *1 (S.D.N.Y. June 18, 2020) (cleaned
up). “A district court has wide latitude to determine the scope of discovery.” In re
Agent Orange Prod. Liability Litig., 517 F.3d 76, 103 (2d Cir. 2008).
B. Plaintiffs’ Motion to Compel
Currenex does not dispute the relevance of the source code for its matching
logic or of the related materials that Plaintiffs request. Further, Currenex never
disputes that production of these documents is proportional to the needs of this
case. Plaintiffs have explored potential alternatives to production of the Currenex
source code, but concluded that they are not reasonable substitutes for the actual
8
source code. Currenex advances no argument to the contrary and does not assert
that producing its source code and related documents would impose a burden
outweighing the likely benefit of this production.
Because the Court determines that Currenex’s source code and related
documents are relevant to Plaintiffs’ claims and proportional to the needs of the
case, Currenex must produce them.
C. Defendant Currenex’s Cross-Motion to Compel
1. Relevance
While the relevance of the Currenex source code is clear—Plaintiffs allege
misrepresentation of the tiebreaking rules and the source code is where those rules
reside—the same is not true of XTX’s source code. Thus, Currenex cannot simply
rely on the fact that Plaintiffs are seeking the Currenex source code to justify
production of the XTX source code. Instead, Currenex must explain why the XTX
source code is relevant in its own right.
Currenex contends that the XTX source code is relevant to issues of causation
and damages, including how XTX “would have traded differently” had it known the
alleged tiebreaking rules. July 9 Letter at 3. In particular, Currenex points to
Plaintiffs’ allegation that they “would have stopped trading on the Platform if they
had known [how] the Platform was actually being operated.” SAC ¶ 164. Currenex
seeks to test this allegation and has presented six arguments for why the XTX
source code is relevant. Each of these arguments is addressed below.
9
First, Currenex argues the XTX source code will show the criteria XTX used
“to select trading venues,” meaning why XTX traded through Currenex instead of
other FX platforms. July 9 Letter at 3. In response, XTX cites the Smart
Declaration, which states that the XTX source code would not show the criteria used
to select trading venues because “such decisions are made by human personnel.”
Smart Decl. ¶ 5. Elaborating on this statement, the Smart Declaration describes
the four factors that its human decisionmakers consider when deciding whether to
trade on a particular venue. Smart Decl. ¶ 6. The Smart Declaration further
suggests that XTX develops trading algorithms that are specific to each trading
venue. See Smart Decl. ¶ 6 (“If a venue passes such conditions, it is only then that a
trading algorithm is developed to trade upon that venue.”).
Currenex’s reply provides no direct response to XTX’s denial that its source
code plays any role in selecting trading venues. Instead, Currenex asserts on reply
that the XTX trading algorithm adjusts trading volumes based on “observed
execution quality and prices/spreads.” July 22 Letter at 1. To the extent this is a
statement about adjusting trading volumes between competing FX platforms, it
simply ignores the Smart Declaration without any supporting evidence and without
explaining why the Smart Declaration should not be credited. To the extent this is
a statement about adjusting trading volumes within the Currenex platform, it would
introduce a new relevance argument on reply, which should not be considered. See
July 9 Letter at 3 (arguing relevance of why Plaintiffs traded on Currenex “vs other
platforms”). But even considering a new argument along these lines, Currenex fails
10
to explain the relevance of adjustments of trading volumes within the Currenex
platform. To the contrary, in explaining the relevance of XTX’s source code, the
July 9 Letter highlights a paragraph of the Second Amended Complaint in which
XTX alleges that, if had known the truth, it would not have traded on the Currenex
platform at all, which is an allegation about choosing among competing platforms,
as opposed to deciding how to trade within the Currenex platform. For the
foregoing reasons, Currenex’s first argument fails to demonstrate the relevance of
the XTX source code.
Second, Currenex argues that XTX’s source code will show whether
Plaintiffs “pursued trading strategies that would have enabled them to profit from
the conduct they allege.” July 9 Letter at 3. XTX responds that “[n]o version of any
XTX source code would show whether XTX profited from the conduct alleged.”
Smart Decl. ¶ 8. Instead, Smart explains that whether and when XTX profited from
the Currenex tiebreaking rules would be evident from Currenex’s transaction
records, not any computer code. Smart Decl. ¶ 8; July 17 Letter at 2. Currenex’s
reply fails to deny that its own transaction records would show whether XTX
profited and by how much. Instead, it asserts that transaction records would not
show “why” XTX traded the way it did. July 22 Letter at 1. But Currenex fails to
explain how this “why” question connects to the relevance arguments originally
11
advanced in its July 9 Letter.4 Without such an explanation or a direct response to
the Smart Declaration, this second argument fails to demonstrate relevance.
Third, Currenex argues that XTX’s source code will show how XTX
evaluated “execution quality” on Currenex’s platform and how that evaluation
affected “subsequent order routing.” July 9 Letter at 3. XTX rebuts this argument
head-on: “[n]o version of any XTX source code would show how XTX assesses the
execution quality of different platforms.” Smart Decl. ¶ 9. Instead, these
assessments are conducted manually by humans. Smart Decl. ¶ 9. Without
offering any declaration of its own or explaining why the Smart Declaration is not
credible in this regard, Currenex’s reply doubles down on its assertion that the XTX
algorithm allocates trades across different platforms. See July 22 Letter at 2
(claiming the XTX algorithm “continuously adjusts volumes routed to various
platforms”). Having offered no direct rebuttal of or reason to doubt the contrary
statements in the Smart Declaration, Currenex fails to substantiate its third
relevance argument.
Fourth, Currenex argues that XTX’s source code will show whether XTX
“evaluated spreads across platforms on a real-time basis.” July 9 Letter at 3. XTX
responds that “[n]o version of any XTX source code would show how XTX evaluates
spreads.” Smart Decl. ¶ 10. These evaluations are conducted manually by humans
4 In explaining the relevance of “why” Plaintiffs traded the way they did, the July 9 Letter
argued, “[k]nowing why Plaintiffs traded on Currenex (vs other platforms) for any
particular trade is key to evaluating whether the Platform’s tiebreaking rules had any
impact on them at all (and, if so, how to measure that impact).” July 9 Letter at 3. This is
an argument about choosing between platforms, not about trading within a given platform.
12
and on a post-trade basis. Smart Decl. ¶ 10. Just like the parties’ exchange in
connection with Currenex’s third argument, Currenex never directly disputes the
Smart Declaration on this point, either by submitting its own declaration or by
explaining why the Smart Declaration should not be credited. Instead, Currenex
simply asserts that the XTX trading algorithm makes continuous comparisons
“based on actual prices and spread across platforms.” July 22 Letter at 2. In the
absence of independent evidentiary support for this assertion or any analysis to
explain why the Smart Declaration is incorrect, Currenex’s fourth relevance
argument fails.
Fifth, Currenex argues that XTX’s source code will show whether XTX
“actually missed out on trades they otherwise would have consummated based on
the Platform’s tiebreaking rules.” July 9 Letter at 3. XTX counters that “[n]o
version of any XTX source code would show which trades XTX tried to execute, but
were prevented from executing” due to Currenex’s alleged conduct. Smart Decl. ¶
11. Any unfulfilled bids or offers would be reflected only in transactional data.
Smart Decl. ¶ 11. On reply, Currenex asserts that the source code could show
“when and how XTX would have exited positions that it would have acquired.” July
22 Letter at 2. But Currenex fails to explain what it means by this, why such exits
are relevant, or why any arguably relevant information is not available from
alternate sources. Indeed, XTX’s July 17 Letter expressly invited Currenex to
explore alternative discovery methods, such as the production of different records,
13
interrogatory responses, and depositions. Currenex’s reply is therefore insufficient
to demonstrate that the source code is relevant.
Sixth, Currenex argues that XTX’s source code will show whether XTX was
harmed due to a Trading Defendant’s use of the “last look” feature to reject trades.
July 9 Letter at 4. XTX retorts, “[n]o version of any XTX source code would show
which trades were entered into after an attempted trade on Currenex was rejected
using ‘last-look.’” Smart Decl. ¶ 12. Any trades entered after an earlier trade was
rejected would be reflected only in transactional data. Smart Decl. ¶ 12. On reply,
Currenex claims that the XTX algorithm “automatically routed rejected trades to
other trading platforms.” July 22 Letter at 2. Again, this assertion ignores the
Smart Declaration, which denies that XTX’s algorithms operated across platforms,
without providing any evidentiary support or describing any specific reason to doubt
the Smart Declaration. But even if this assertion were supported, the prices and
other details about subsequent trades would be reflected in the transactional
records of the other platforms where such trades were executed. Currenex’s
statement that “none of those replacement trades will be reflected in Currenex’s
transactional data” misses the point. July 22 Letter at 2. The replacement trades
would be reflected in the transactional data of other platforms, not in XTX’s
algorithms. Currenex fails to explain why the source code would contain such
information and fails to support its relevance argument.
Additionally, Currenex asserts that XTX’s source code is relevant to class
certification issues of typicality and predominance. July 9 Letter at 4. Currenex
14
claims that XTX’s source code “might reveal . . . some idiosyncratic trading
methodology,” but does not elaborate further or provide any specific basis to believe
that is the case. July 9 Letter at 4. This argument is too speculative to be given
any weight.
Currenex cites two decisions in support of its cross-motion, but both are
distinguishable. In Dynamic Microprocessor Assocs. v. EKD Computer Sales, 919 F.
Supp. 101 (E.D.N.Y. 1996), the party seeking production of source code filed
affidavits by software experts explaining why they needed the source code to
analyze questions of functionality and similarity that were critical to the copyright
and contract claims asserted in that case. Currenex offers nothing comparable
here. In Moog, Inc. v. Skyryse, Inc., 2022 WL 16852364 (W.D.N.Y. July 22, 2022),
the court required the plaintiff to identify its asserted trade secrets, which were
source code. This decision rested on the principle that trade secret litigation
requires a precise identification of what trade secrets are claimed. The claims in
this case are not analogous. See also Congoo, LLC v. Revcontent LLC, 2017 WL
3584205, at *3 (D.N.J. Aug. 10, 2017) (distinguishing between cases in which
production of source code is necessary to prove claims, like patent infringement
cases, from cases in which the relevant information can be obtained without review
of the actual code).
Here, XTX submitted a sworn declaration providing a point-by-point
refutation of Currenex’s relevance arguments. Currenex filed a reply, but it did not
directly address the Smart Declaration. Instead, Currenex’s reply either repeated
15
assertions about cross-platform comparisons that the Smart Declaration had
denied, or shifted focus to making assertions about the XTX source code adjusting
trading within the Currenex platform, but without adequately explaining how such
in-platform adjustments relate to the claims and defenses in the case. Accordingly,
Currenex has not met its “initial burden of proving [XTX’s source code] is relevant.”
Sheindlin v. Brady, 2021 WL 2075483, at *2 (S.D.N.Y. 2019).
2. Proportionality
Even if Currenex had met its burden to demonstrate the relevance of XTX’s
source code, Currenex makes no attempt to rebut XTX’s showing that requiring
production of its source code is not proportional to the needs of the case given the
sensitivity of the source code, the burden of producing it, and the potential
availability of alternate means to obtain the information in question.
Currenex never disputes that XTX’s source code is highly sensitive and
proprietary information. The Smart Declaration states that these algorithms were
created as “the result of approximately a combined 25+ man-years of research effort
and the expenditure of millions of dollars.” Smart Decl. ¶ 14. Further, these lines
of computer code are “carefully-guarded secrets” protected by both information
security technology measures and limited access to select personnel who are subject
to higher legal obligations than those without access to the source codes. Smart
Decl. ¶ 15. Indeed, XTX characterizes its trading algorithms as the “lifeblood” and
“crown-jewel assets” of the company, which constitute “the entirety of XTX’s
intellectual property.” Smart Decl. ¶ 14. XTX further claims that if its source code
16
or trading algorithms were disclosed to a competitor or to the public, “it would
destroy the firm.” Smart Decl. ¶ 14. These are bold assertions, yet Currenex never
disputes them or suggests that they are exaggerated.
XTX also argues that the complex and expensive undertaking of producing
the source code is not proportional to the needs of the case. The Smart Declaration
explains that “[i]t would take hundreds of hours of staff time to review, identify and
extract the relevant information from the code-base” and “to determine how to
transfer the source codes to Defendants in the most technologically secure manner.”
Smart Decl. ¶ 16. XTX claims that such a herculean effort would prevent the small
number of personnel who have access to the code from performing their regular
duties and “would have a material financial cost to the firm.” Smart Decl. ¶ 17.
Again, Currenex makes no attempt to dispute XTX’s assertions as to the extremely
high burden and expense that production would impose.
Finally, XTX identifies less intrusive ways to provide the information that
Currenex seeks. It suggests, for example, that Currenex can obtain this
information through a stipulation identifying the functional aspects of XTX’s
trading algorithm, or through interrogatories and deposition testimony. Whether
those alternatives prove fruitful remains to be seen. But given Currenex’s failure to
substantiate the relevance of the XTX source code or to address the burden and
hardship that production of the source code would impose, Currenex’s failure to
explore these other methods of discovery provides yet another reason to deny its
motion to compel.
17
In the end, the burden of producing XTX’s source code is indisputably high,
and Currenex does not demonstrate that there is any likely benefit of such
production, let alone a benefit that would outweigh the associated burden. Thus,
even if Currenex had met its initial burden of demonstrating that XTX’s source code
is relevant, production of the XTX source code is not proportional to the needs of the
case.
lil. CONCLUSION
For the reasons set forth above:
(1) Plaintiffs’ motion to compel the production of Currenex’s source code
and related documents is hereby GRANTED. Currenex is directed to produce the
source code containing its matching algorithm and related documents as described
in Request 49.
(2) Currenex’s cross-motion to compel the production of Plaintiffs’ trading
algorithms is hereby DENIED.
The Clerk of Court is respectfully directed to terminate the open letter
motion at ECF No. 132.
SO ORDERED.
Dated: October 11, 2024 CL
New York, New York
He J. Ricarflo
United States Magistrate Judge
18