Case Study: Patching Together a Virtual Brokerage with Off-the-Shelf APIs
The initial state was a predictable mess. A new virtual brokerage, launched in a hurry, operated on a toxic combination of Salesforce, a third-party market data feed, and a legacy SQL database for compliance tracking. Their “remote collaboration tool” was a chaotic web of Slack DMs and email chains. Trade approvals were requested, missed, and then frantically chased down. Data consistency was a fantasy.
This wasn’t a scalability problem. It was a structural failure waiting to happen. The core challenge was forcing an auditable, synchronous-feeling workflow onto a set of fundamentally disconnected, asynchronous systems. All without a nine-figure budget to build a proprietary platform.
The Problem: Unstructured Data and Zero Audit Trail
A broker would identify a trade opportunity. They would then manually pull client suitability data from Salesforce, check market data from one browser tab, and then email a compliance officer with the details. The officer, swamped with requests, would have to manually cross-reference the client ID against their own SQL database. The entire process was opaque, slow, and generated zero machine-readable logs.
Regulators don’t accept “we think Bob emailed Susan” as a valid audit trail. Every action, from proposal to execution, needed to be timestamped, attributed, and immutable. The existing process was the digital equivalent of scribbling trades on cocktail napkins. A single fat-fingered client ID in an email could lead to a catastrophic compliance breach.
The mandate was clear. We had to inject structure and accountability into the workflow. We also had to do it with the existing tools, because the budget for new platform licenses was nonexistent. This meant the solution had to be built on API calls and webhooks, a fragile bridge over their chaotic infrastructure.
The Fix: Forcing Structure with a Central Automation Service
We didn’t replace their tools. We subjugated them. The first step was to kill the free-for-all communication. We migrated them from Slack to Microsoft Teams, not because Teams is inherently superior, but because the Microsoft Graph API is more predictable for creating structured, auditable containers for communication.
Every client in Salesforce would now have a corresponding private channel in Teams. This wasn’t done manually. A central Python service running on AWS Lambda listened for Salesforce webhooks. A `new_client` event would trigger the service to perform a sequence of actions:
- Create Channel: It calls the Graph API to create a new private channel named with a strict convention, like `CLIENT-[Salesforce_Account_ID]`.
- Add Members: It automatically adds the assigned broker and a compliance officer from a rotating pool to the channel. No more guessing who to contact.
- Inject Context: The service then pulls key client data from Salesforce and the compliance SQL database. It formats this data into a Microsoft Adaptive Card and posts it as a pinned message in the new channel. This card contains the client’s risk tolerance, investment history, and any compliance flags.
The broker no longer needs to hunt for information. The context is forced upon them the moment the channel is created.
This architecture turned a messy, multi-step research process into a single, event-driven action. The Lambda function acts as the central nervous system, reacting to a stimulus from one limb (Salesforce) and coordinating the response in another (Teams). The entire setup is just a collection of API calls stitched together with Python logic. It’s brittle, but effective.
Orchestrating the Trade Approval Flow
With the communication channels structured, we tackled the trade approval process. We built a simple bot command within Teams. A broker types `/propose_trade [TICKER] [QUANTITY] @ [PRICE]` directly into the client’s dedicated channel.
This message hits a webhook configured for the Teams bot. Our Lambda function ingests this payload. The function’s logic is sequential and unforgiving:
- Parse the Message: Strip the string to isolate the ticker, quantity, and price. Basic string manipulation, but a common failure point if a broker gets sloppy with syntax.
- Pre-flight Checks: The service makes a synchronous call to the compliance SQL database with the client ID and trade details. It runs a stored procedure to check against suitability rules and restricted lists.
- Generate Approval Card: Based on the compliance check result, the service generates another Adaptive Card. This card displays the proposed trade, the outcome of the compliance check (e.g., `PASS: SUITABILITY_OK`), and two buttons: `Approve` and `Reject`. This card is posted back into the channel, directly mentioning the compliance officer.
- Log the Decision: When the officer clicks a button, that action sends a payload back to our service. The service logs the decision (Approve/Reject), the timestamp, and the officer’s user ID to a separate, immutable log table in a dedicated PostgreSQL database. This is the real audit trail.
The old method of passing information around was like trying to shove a firehose through a needle. This new system containerizes each request, validates it, and tracks it through a defined, narrow pipeline. There is no room for ambiguity.
Here is a simplified Python snippet illustrating the logic for posting the final approval card. It assumes `requests` is installed and you have a valid bearer token for the Graph API.
import requests
import json
def post_approval_card(webhook_url, trade_details, compliance_status):
"""
Posts an Adaptive Card to a Teams channel via an incoming webhook.
"""
card_payload = {
"type": "message",
"attachments": [
{
"contentType": "application/vnd.microsoft.card.adaptive",
"content": {
"type": "AdaptiveCard",
"$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
"version": "1.2",
"body": [
{
"type": "TextBlock",
"text": "Trade Approval Request",
"weight": "bolder",
"size": "medium"
},
{
"type": "FactSet",
"facts": [
{"title": "Client ID:", "value": trade_details['client_id']},
{"title": "Ticker:", "value": trade_details['ticker']},
{"title": "Quantity:", "value": str(trade_details['quantity'])},
{"title": "Price:", "value": f"${trade_details['price']}"}
]
},
{
"type": "TextBlock",
"text": f"Compliance Check: {compliance_status['message']}",
"color": "good" if compliance_status['passed'] else "attention",
"weight": "bolder"
}
],
"actions": [
{
"type": "Action.Submit",
"title": "Approve",
"data": {
"action": "approve",
"trade_id": trade_details['id']
}
},
{
"type": "Action.Submit",
"title": "Reject",
"data": {
"action": "reject",
"trade_id": trade_details['id']
}
}
]
}
}
]
}
headers = {'Content-Type': 'application/json'}
response = requests.post(webhook_url, data=json.dumps(card_payload), headers=headers)
# Basic error check, production code needs retry logic.
if response.status_code != 200:
print(f"Error posting card: {response.status_code} {response.text}")
return response.status_code
This isn’t rocket science. It’s a simple HTTP POST. The value is not in the complexity of the code, but in the enforcement of the workflow. The code forces a human to make a binary decision on a pre-validated piece of data.
Results: The Metrics That Actually Matter
The project wasn’t about making people “feel” more productive. It was about reducing risk and compressing timelines. We measured success with three key performance indicators.
KPI 1: Trade Approval Latency. The old email-based system had a median approval time of four hours, with outliers stretching into the next business day. The new system brought the median approval time down to seven minutes. This is the time from the broker’s `/propose_trade` command to the compliance officer’s click on `Approve`.
KPI 2: Reduction in Reconciliation Errors. Manual data entry from emails to the trade log was responsible for about 5% of all trades having an error that required manual reconciliation. By making the process entirely API-driven, we eliminated this class of error. The error rate for logged trade data dropped to effectively zero. The only remaining errors were from brokers mistyping the initial command.
KPI 3: Audit Trail Compilation Time. Previously, responding to a regulatory request for a specific client’s trade history took an average of 20 person-hours. It involved a paralegal searching through email archives and chat logs. With the new system, we wrote a script that queries the PostgreSQL log database and the Teams channel history via the Graph API. It generates a complete, timestamped report in under five minutes.
The Inevitable Trade-Offs
This system is not a robust, high-availability platform. It is a chain of dependencies. If the Microsoft Graph API has an outage, our entire approval workflow halts. If Salesforce changes a webhook payload without notice, our service breaks. We traded the chaos of manual work for the anxiety of constant API monitoring.
The automation service itself became a critical single point of failure. To mitigate this, we had to build out extensive logging and alerting using CloudWatch. An API call that returns a `502 Bad Gateway` now triggers a PagerDuty alert. We also created a “break glass” manual override protocol, which involves falling back to a monitored email inbox. It’s clunky and painful, but it prevents a total shutdown.
The reliance on third-party APIs also means we are subject to their rate limits. During periods of high market volatility, we saw an increase in trade proposals that led to API throttling from both Salesforce and Microsoft. We were forced to refactor parts of the Lambda function to include exponential backoff and a queuing mechanism using SQS. This added complexity and cost to what was supposed to be a simple script.
This solution works. It met the primary objectives of auditability and speed. But it is a high-maintenance beast. It proves that you can build functional workflows with modern collaboration tools, but it also shows that the underlying complexity doesn’t disappear. You just shift it from unpredictable human behavior to the deterministic, but fragile, world of API integrations.