.png?width=2000&name=Untitled%20(60).png)
.png?width=1200&height=628&name=Blog%20header-1%20(27).png)
.png)
.png)
.png)
Every OTC desk knows manual trade entry is inefficient. The firms that haven't automated it aren't unaware of the problem. They have specific, reasonable objections that have so far won the argument. Most of those objections were legitimate a few years ago, but not anymore.
These are the six we hear most often.
"Our traders use too much shorthand. No system will understand it."
This is the most common objection, and the most understandable. Traders confirm deals in compressed, context-dependent language that varies by client, by commodity, by the relationship between two people who have been trading with each other for years. Early automation attempts failed here. Rule-based systems couldn't parse it. That failure left a lasting impression.
What changed is that the model learns at the level of the individual trader. It trains on the patterns of each person: the shorthand they use, the counterparties they deal with, the locations and indices they reference. A nickname for a pipeline location, a two-word instruction that references yesterday's trade, a confirmation that only makes sense in the context of an ongoing conversation. If a human can decode it, the model can be trained to as well.
In production, field-level accuracy across ipushpull's customer base exceeds 90%. At Koch Energy Services, one of North America's largest physical gas traders, the model learned the specific language of their traders and continued to improve with every trade processed.
"We'd need a direct API integration with our chat platform. That's expensive and complicated."
This objection stops more trials than any other, and it is based on a misunderstanding of how the tool actually works.
A direct real-time API feed from a chat platform is one option. However, ipushpull customers find it just as easy to use a copy-paste approach: a trader selects a snippet from their chat window, pastes it into the ipushpull interface and presses capture. The inference engine does the hard work. The trader reviews and confirms. The whole process takes a few seconds per trade.
This means trials can be running within days of signing an NDA, with no API approval process, no additional platform fees and no integration project standing in the way. Real-time API ingestion is available for firms that want to remove the paste step entirely, and is the direction the platform is heading. It is not a prerequisite for getting value on day one.
"It won't connect to our back-office system."
The trial period does not require a back-office integration. Firms can run a full trial outputting to CSV or Excel, and validate that the system is capturing trades accurately and completely.
Once you're ready to go forward, our API connector makes things easy, meaning an API connection can take as little as a couple of hours of configuration by one of our API Market Experts. The platform has been connected to multiple ETRM systems, OMS platforms and bespoke proprietary systems across energy, derivatives and fixed income. Reference data is mapped to the firm's own naming conventions: counterparty names, contract codes and delivery locations, all translated directly into the terminology the downstream system already uses.
"We don't do enough volume to justify the cost."
This one comes up almost every time, and it reflects a common but mistaken assumption: that trade capture automation only makes commercial sense at high volume.
The value is in error rate, time and compliance exposure, not volume. A desk doing ten to twenty trades a day in a manual workflow is spending significant time on data entry that should take seconds. Every miskeyed field is a potential settlement dispute, a compliance gap, a correction that someone has to trace back through chat logs weeks later. At ten trades a day, the cost of one error caught late is typically higher than the annual cost of the platform. Koch Energy Services reduced trade-entry time by 85% across more than 50,000 trades. The same proportional saving applies at a tenth of that volume.
ipushpull has clients ranging from a handful of users putting through a few dozen trades a week to large desks processing tens of thousands. The economics do not depend on scale. They depend on how much time is currently being spent on something a computer should be doing.
"What happens to our compliance trail and trade reconstruction?"
The business case for trade capture automation is rarely made in a planning meeting. It is made after a settlement dispute, a regulatory query, or an audit that requires someone to go back through months of chat logs and match conversations to deal records. That process can take days. Sometimes weeks.
When a trade is captured through ipushpull, the source conversation is attached to the trade record. The timestamp, the participants, the exact text of the agreement: all stored and linked at the point of capture, not reconstructed after the fact. Tracing a disputed trade back to its origin becomes a search query rather than an investigation. Every confirmation step is logged as a discrete event with full provenance.
This capability matters equally across markets. In energy, it closes the loop between the chat log and the ETRM record. In OTC derivatives and fixed income, it provides the audit trail that regulators expect and that manual workflows routinely fail to produce cleanly.
"Our data will be used to train a model that benefits our competitors."
The training data that drives accuracy is private per firm. The shorthand a trader uses, the counterparty nicknames, the pipeline or instrument references, the patterns the model has learned over months of production use: none of this is shared across customers. Every correction a trader makes improves the model for that firm only. The accuracy built up over time belongs to the firm.
Data is hosted by ipushpull as part of the SaaS service. But the learning data is kept separate per customer by design. The version that understands how your desk trades is yours. It does not become part of a shared dataset that a competitor benefits from.
The objection that remains
None of the above is a reason to keep doing this manually. The accuracy question has been answered in production, the integration requirements are lower than most firms assume, and the compliance case is strong at any volume.
The objection that does remain is the one that cannot be answered with a product feature: the internal decision to act. The desks still entering trades by hand in 2026 are not doing so because the technology isn't ready. They are doing so because the case hasn't been made internally yet, or the right meeting hasn't happened, or there is always something more urgent.
The settlement dispute that takes three weeks to resolve usually changes the calculation. Most desks make it after.
Related reading:
