finos / finos/traderX

Open Source in Finance Hackathon NYC 2025 - TraderX Track challenges

Open
#304 3 comments 1 reaction 0 assignees View on GitHub
Dominant language
Shell
Stars
106
Forks
146
Avg merge
21d 40m
Merged PRs (30d)
1

Description

The [Open Source in Finance Hackathon](https://www.finos.org/hosted-events/2025-10-15-open-source-in-finance-hackathon-nyc) (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`.

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the proposed tracks and use cases in this issue, along with the linked FINOS event page. Identify which challenge is actually in scope and confirm it with maintainers; done means one actionable, agreed TraderX hackathon challenge with clear success criteria rather than an open collection of proposals.

Written by the indexing model from the issue text.

Assessment

Tech stack
helm, kubernetes, spring-boot
Domain
content, documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.