Savvycom Fintech Compliance Case Study: FX Assistant in 90 Days
A South Korea-based financial services company that handles high-frequency BUY/SELL transactions and real-time rate inquiries asked us for faster FX operations without loosening control. We delivered a five-agent AI assistant inside Mattermost in three months, roughly 90 days. It cut FX processing time by 60% and improved operational efficiency by 40%.
The client already ran its internal communication in Mattermost, so the brief was to bring FX operations into that channel rather than replace the tools its team used every day. Users check rates, manage settlement rules, and execute trades in natural language, and the system enforces the controls a trading desk needs underneath.
This is an account of how that assistant works and where the compliance controls sit. The full project summary is on our portfolio: Multi-Agent AI for Foreign Exchange Operations in South Korea.

A five-agent AI assistant embedded in Mattermost cut FX processing time by 60% while keeping quote locking, role-based access, and audit logging built into every transaction
1. What Was Slowing FX Operations Down?
The client faced four problems, and three of them were control problems rather than speed problems. Rate checking and trade confirmation were slow and labor-intensive as volume grew, but the deeper risk was that manual settlement handling, quote validity, and role-based access had no systematic enforcement.
- Manual FX operations. Rate checking and trade confirmation were slow and labor-intensive as transaction volume grew.
- Complex trading rules. Settlement handling, quote validity, and BUY/SELL logic all needed strict, consistent enforcement.
- Inconsistent rate risk. Periodic and on-demand rates could cause confusion without proper locking.
- Approval and access control. Secure execution required clear role-based permissions.
Speed alone would have been an easy brief. A faster assistant that lets the wrong person change settlement rules or executes a trade at a rate the user never confirmed creates more risk than the manual process it replaced. The design had to make the fast path and the controlled path the same path.
2. How the Five-Agent Design Works
Each agent owns one part of the FX workflow, so each part carries its own rules and permissions. Splitting responsibilities this way means a change to settlement rules touches one agent and one permission boundary, not the whole assistant.
The assistant is a multi-agent system built with LangGraph and GPT-4o, embedded in Mattermost. It has five agents:
- User Management Agent. Role-based member and permission control.
- FX Rate Agent. On-demand rates for exchange and periodic rates for reference.
- Settlement Agent. Channel-level BUY/SELL settlement configuration, with admin-only access.
- Exchange Agent. Chat-based BUY/SELL execution with quote ID locking, confirm or reject, and automatic re-quote on expiry.
- Transaction Agent. Search and review of past FX transactions directly in the chat channel for audit and tracking.
The supporting stack is Python, PostgreSQL, Redis, REST APIs, and Docker, deployed on AWS in a hybrid setup.

The five-agent architecture assigns each workflow stage its own rules and permission boundary, so a change to settlement configuration touches one agent only
3. How Does Quote ID Locking Keep Rates Under Control?
Quote ID locking ties each confirmed trade to one specific quoted rate, so the rate a user confirms is the rate that executes. If the quote expires before confirmation, the assistant requests a fresh quote automatically rather than executing at a stale rate.
Locking and expiry
The Exchange Agent locks a quote ID when a user starts a BUY or SELL. The user then confirms or rejects. If the quote expires before confirmation, the assistant requests a fresh quote automatically instead of executing at a stale rate. The pattern is consistent with standard FX infrastructure practice: Goldman Sachs Transaction Banking documentation confirms that a held-rate quote lapses if it is not accepted and a new quote must be requested.
Reference rates versus executable rates
The FX Rate Agent serves two kinds of rates: on-demand rates for exchange and periodic rates for reference. Keeping them separate addresses the confusion the client had seen when different rates circulated in the same channel. A periodic rate informs a decision. Only a locked, on-demand quote can be traded.
4. Access Control and the Audit Trail
Permissions and logging are built into the workflow itself, not added as a review step afterward. Every transaction is logged automatically, and settlement configuration is admin-only, so the controls cannot be bypassed by the pace of a busy trading desk.
Role-based permissions
The user management agent controls who can do what in the channel. Settlement configuration is admin-only, and execution runs through quote locking and admin approval controls. A regular user can request rates and trade within the rules but cannot change the rules.
Automatic logging
Every transaction is logged automatically for compliance and audit. The Transaction Agent lets authorized users search and review past FX transactions without leaving Mattermost, so an audit question can be answered in the same place the trade was made.
5. What the Project Delivered
The assistant went live after a three-month project and delivered measurable gains across speed, efficiency, and compliance. The 60% and 40% figures reflect this client’s starting point and workflow; teams with different volumes or manual processes should treat them as a reference point, not a forecast.
| Outcome | Result |
| FX processing time | 60% reduction |
| Operational efficiency | 40% improvement |
| Compliance and audit trail | Automatic logging, role-based access, and quote locking reduced trading risk |
| Build timeline | 3 months (five-agent system, Mattermost integration) |
| User adoption | Built into the existing Mattermost channel, no tool migration required |
6. What This Project Tells You About Compliance in AI-Assisted Trading
Compliance in a chat-based trading tool comes from where the controls sit, not from the number of approval steps. Every control in this project lives inside the workflow: the quote is locked before the trade, settlement settings are admin-only, roles are checked before actions, and logging happens automatically.
A control that depends on a user following a checklist fails the first time the desk is busy. A control built into the path cannot be skipped.
The second lesson is adoption. The assistant lives in the channel the team already used, so there was no new tool to learn and no second place to record a trade. For regulated workflows, that matters as much as the model: a compliant system that people route around is not compliant in practice.






