Open Source in Finance Hackathon NYC 2025 - TraderX Track challenges

[karlmoll]

The Open Source in Finance Hackathon (Organized by FINOS & hosted by AWS) will contain a TraderX track - the following challenges have been curated based on maintainer feedback:

TraderX Hackathon: Proposed Tracks and Use Cases

During the January TraderX community call, the “feature branches”/Swim Lanes approach was introduced. The idea was presented that a hypothetical “TraderX Conference” could be divided into 3 tracks. The following Use Cases have been collected from several calls since then (notably Jan 24 & Aug 22) and organized along these tracks.

---

Track 1: Developer Experience

This track focuses on the developer tooling and the ideal experience for building and deploying multi-container applications in a large, regulated organization.

• Improving the Developer Experience with Radius
  • Objective: Use Radius to simplify the deployment of TraderX, creating a higher-level abstraction over the complexities of Kubernetes and Helm charts.
• Implementing Liveness and Readiness Probes
  • Objective: Add liveness and readiness probes to all TraderX microservices to ensure Kubernetes can automatically manage the application's health, making it more robust and easier to operate.
• Generative AI for Automated, Compliant Documentation
  • Objective: Use an AI model to automatically generate developer documentation for TraderX feature branches that adheres to a predefined set of compliance rules and best practices relevant to regulated firms.
• Visualization & Branch Management Tool
  • To Be Defined

---

Track 2: Infrastructure and Non-functional Improvements

This track is for large-scale infrastructure changes, architectural reworkings, and cross-cutting concerns like security, documentation, and observability.

• "Bake-Off" Service Mesh Implementation
  • Objective: Compare different vendor offerings - Deploy a service mesh on top of TraderX to enforce security policies (like mTLS) and gain detailed observability into application traffic without changing the application's source code.
• Event-Driven Architecture with Drasi
  • Objective: Re-imagine TraderX's core data flow by implementing a truly event-driven model with Drasi, where services react to data change events directly from the source rather than making traditional database queries.
• Integrating Authentication with an Identity Provider
  • Objective: Integrate an external identity provider to manage user authentication for TraderX, moving security logic out of the application and into a centralized, secure service.
• App Modernization with Quarkus and Serverless Functions
  • Objective: Replace an existing Spring Boot microservice in TraderX with a more efficient, cloud-native implementation using Quarkus, and deploy it as a serverless function.

---

Track 3: Application Functionality

This track focuses on adding or enhancing the core business capabilities of the TraderX platform.

• Challenge: Add Trading
  • Real Time Pricing
  • Adding market order
  • Adding data
• Adopting the Common Domain Model (CDM)
  • Objective: Refactor a TraderX service to use the FINOS Common Domain Model (CDM) for its data structures, demonstrating how to align the trading application with industry-wide data standards.
• FDC3 Integration
  • Add FDC3 support to TraderX.
  • Write a directory entry (appD).
  • Show it running in sail.fdc3.finos.org.

[willtsai]

Bake-Off" Service Mesh Implementation
Objective: Compare different vendor offerings - Deploy a service mesh on top of TraderX to enforce security policies (like mTLS) and gain detailed observability into application traffic without changing the application's source code.

For this item in Track 2, I recommend leveraging CNCF's Dapr instead of a traditional service mesh as Dapr's Service Invocation feature offers the same capabilities (mTLS, observability without changing app source code) plus other built-in features like abstractions to standardize API calls between services and retries for resiliency.

[karlmoll]

Hackathon Track: Visualization & Branch Management Tool

One of the key challenges for the TraderX project is managing its evolution as a "knowledge graph" with multiple distinct states or "journeys". As we add new features (like Postgres integration) or experiment with different deployment models (like Radius or GitOps) , we want to avoid overcomplicating the main branch so that it remains approachable for newcomers.

The goal of this hackathon track is to create a tool or process that can visualize these different states of the project and help developers start new work from a clean, logical baseline.

What Success Looks Like:

Reconstruct a "Clean History": Create a new branch that reconstructs the project's history as a series of clean, logical commits. This would start with a base version (shell scripts), add a commit for containerization (Docker Compose) , and then another for infrastructure hardening (e.g., adding Postgres).

Visualize the Graph: Generate a visual representation of the project's state diagram. This could be a Mermaid diagram embedded in a README, an interactive chart on a documentation site, or a component in a developer portal like Backstage.

Create a Branching Tool/Process: Develop a script or a well-documented process that allows a developer to easily check out a specific "clean" state of the project (e.g., "the version with Docker Compose but before Postgres was added").

This will make it much easier for future contributors to understand the project and start new feature branches from the correct point in its history.

Relevant Reading:
Initial "Swim Lanes" Diagram & Discussion: TraderX GitHub Issue #304

Dov Katz's Mermaid Diagram & "Knowledge Graph" Comment: Comment on Pull Request #308

The "Learning Path" Branch: TraderX Learning Path Branch