Edmar Financial Company, LLC v. Currenex, Inc.

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 CrossMotion 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 crossmotion 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 crossmotion. 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 nondispositive 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 —