UBS × Singapore Management University
KAIROS
Turn trading-system logs into actionable telemetry and conversational diagnostics.
Software Engineer · Scrum Master · Aug–Dec 2026
Summary
KAIROS is a telemetry platform built for a UBS-sponsored university project. Lightweight agents process trading and application logs near their source, publish structured metrics to a central backend, and expose diagnostic queries through a Teams bot and a read-only Model Context Protocol (MCP) interface.
It helps support engineers investigate order rejections, connectivity issues and application failures without searching logs across individual hosts. The prototype was developed and tested with representative, synthetic data rather than a live production trading environment.
Problem
Diagnosing a trading incident can mean reaching into several hosts and correlating separate log streams to learn whether orders were rejected, sessions disconnected or an application stopped responding. That is slow, fragmented and hard for people who need an operational answer rather than raw log output.
The challenge was to provide timely, queryable visibility without disturbing latency-sensitive host applications or sending sensitive raw logs off their source systems, and to keep alerts working when the central backend was briefly unreachable.
Architecture
↳ Hover or focus any component to see what it connects to.
KAIROS runs on the host server beside the trading application. Inside the host boundary, the host application owns the FIX and application log files and a callback endpoint. A separate KAIROS telemetry agent reads the logs through a log monitor and FIX parser, then a metrics and local alert evaluation step. From that step two independent paths leave. One goes to an asynchronous batch publisher, which sends batched telemetry and health snapshots from a bounded queue to a FastAPI telemetry backend. The other goes to a signed callback dispatcher, with retries, backoff and delivery tracking, which calls the host application's callback endpoint for critical alerts, so alerting does not wait on the backend. The backend ingests telemetry, keeps recent metrics in process-local memory and exposes validated query APIs. A Microsoft Teams bot sends requests to those APIs and receives answers. Separately, a Copilot client invokes named tools on a read-only MCP server, which sends requests to the same backend APIs and returns the results.
A host-side telemetry agent follows configured log files, tracks read offsets, handles rotation and feeds bounded processing queues. A FIX parser validates messages and extracts fields; downstream components aggregate counters and latency statistics and evaluate local alert conditions.
Two independent outbound paths leave the host. An asynchronous publisher batches selected metrics to the central service with configurable retry and backoff. Separately, a callback dispatcher sends critical alerts to the host application with signed requests, delivery tracking and retries, so a stalled backend never stalls local alerting.
A FastAPI backend ingests derived telemetry, keeps bounded recent views in memory and exposes validated query APIs. A Teams bot uses those APIs, and a thin read-only MCP server exposes named tools that route to the same query layer rather than duplicating logic.
My Contributions
- Implemented the streaming log monitor and FIX parsing pipeline: file offset tracking, rotation handling, validation and structured event extraction.
- Developed the asynchronous backend publisher in Python and asyncio: batched transmission, configurable retries and backoff when central delivery fails.
- Built the callback dispatcher that delivers critical host-side notifications independently of backend publishing, with retries and delivery tracking.
- Implemented the MCP integration layer, exposing read-only operational queries as named tools backed by the central telemetry APIs.
- Contributed to the system architecture and to cross-team delivery as a software engineer and Scrum Master.
Engineering Decisions
Process at the source. Parsing, validation, and aggregation happen alongside the trading application. Only allowlisted, derived telemetry is published to the backend, reducing sensitive data movement while enabling early detection of local issues. Processing close to the source also requires careful control of CPU, memory, and file I/O to avoid interfering with trading workloads.
Bound memory and isolate failures. Bounded queues and rolling metric windows keep resource usage predictable. When queues reach capacity, older events are evicted to prioritise recent telemetry, trading historical completeness for bounded memory. Alert callbacks and backend publishing operate independently, ensuring backend delivery delays do not directly block critical host-side notifications.
Reuse one query boundary. Teams and MCP share the same validated backend query APIs. That avoids inconsistent logic in each interface and keeps MCP tools read-only.
Short-lived context over unapproved persistence. The prototype keeps recent telemetry rather than raw logs or a long-term audit database. That simplifies data handling but limits historical queries and restart recovery.
Results & Validation
- Built a prototype pipeline spanning log ingestion, FIX parsing, metric aggregation, alert evaluation, callback delivery, backend ingestion and query access.
- Exercised integrated workflows with synthetic logs, including signed callbacks, backend queries and behaviour while backend publishing is unavailable.
- Validated Teams-to-backend interactions in Microsoft's local test playground, including answers, clarification paths and error responses.
- Deployment to a live Microsoft tenant or a production trading environment has not been verified. This is an engineering prototype, not a production UBS deployment.
Stack
- Python
- asyncio
- FastAPI
- Pydantic
- FIX protocol
- pytest
- HTTP/JSON
- MCP
- Microsoft Teams