The Support Blind Spot Between Your Trading Platform and Your Custodians
A Restriction Update That Never Made It Into the Trade
An advisor updates a client's account restrictions on Monday morning, removing a position the client no longer wants held. By Wednesday's rebalancing session, the platform generates a trade that touches that exact position anyway.
Two calls later, the picture hasn't improved:
The platform's support desk checks the restriction settings, confirms they were updated correctly on the platform side, and points to the custodian's data feed as the likely source of the delay.
The custodian confirms the account is flagged correctly on their end and suggests the issue is how the platform is interpreting their feed.
Two calls, two confirmations that everything is working correctly, and one unresolved trade sitting in an account that shouldn't have it.
This pattern reflects a structural reality of how RIAs operate. Unlike a broker-dealer running trades through its own proprietary custody arm, an RIA's trading and rebalancing platform and its custodial relationships are typically provided by entirely separate organizations.
Each has its own support desk, its own definition of what falls inside its responsibility, and no shared incentive to be the one who owns a problem that could plausibly belong to the other.
This blog focuses specifically on the cross-system ownership dimension that guide cannot address in full depth.
Why Problems at the Custodian-Platform Boundary Are Structurally Hard to Resolve
Most support evaluations focus on how quickly a vendor resolves issues that are clearly within their own system. Far fewer examine what happens when the root cause sits at the boundary between the platform and a custodian, because that boundary is where ownership becomes genuinely ambiguous.
Four types of issues surface there most often:
Data timing mismatches.
A custodial feed that updates on a different schedule than the platform's internal state can make a correctly configured account look incorrect, or an incorrectly configured account look fine, depending entirely on when the discrepancy is checked.
Restriction propagation gaps.
A restriction entered on the platform needs to be reflected in how trades are generated, but if the custodian's account records haven't caught up, the trade generated may not reflect the client's current instructions even though both systems, checked independently, appear correct.
Cash and settlement discrepancies.
Cash sweep timing, pending transactions, and settlement delays at the custodian can create a mismatch between what the platform believes is available to trade and what the custodian will actually execute, and neither party's system shows an error on its own.
Corporate action handling.
Splits, mergers, and other corporate actions require coordinated updates between the custodian's record and the platform's model, and a delay or mismatch in either direction can produce trades that are technically correct given the data each system had, but wrong given the client's actual position.
In each of these situations, both the platform vendor and the custodian can accurately state that their own system behaved as designed. The problem exists in the handoff between them, which is precisely the space that neither party's standard support process is built to own.
Five Scenarios That Reveal Whether Cross-System Ownership Is Actually Defined
The five questions below move a support conversation past general responsiveness claims and into how a vendor actually behaves when a problem sits at the edge of what its own system controls.
Each one is designed to surface whether ownership is defined in advance or negotiated after the fact.
Scenario
What to Ask
Strong Answer
Weak Answer Signal
A problem could originate on either side
When a problem could originate at either the platform or a custodian, who at your organization is responsible for driving it to resolution?
A named internal role or team that owns the ticket through resolution even when the fix requires coordinating with the custodian, rather than closing the ticket once the platform side is confirmed correct
The vendor confirms their side is working and directs the client to contact the custodian separately, treating the ticket as resolved from their perspective once their system checks out
A shared issue needs two parties talking directly
Do you have direct working relationships with the custodians we use, or does cross-system coordination happen through us?
An established relationship or communication channel with major custodians that allows the vendor to coordinate directly on a shared issue without requiring the client to relay information between both parties
The vendor has no direct line to custodians and relies on the client to serve as the intermediary, passing information between the vendor's investigation and the custodian's support team
The root cause hasn't been identified yet
What is your response time commitment for an issue where the cause has not yet been identified as platform-side or custodian-side?
A defined response time that applies from the moment the ticket is opened regardless of where the root cause eventually turns out to be
Response time commitments apply only once the issue has been confirmed as platform-side, leaving ambiguous cross-boundary issues without a defined response clock
Ownership needs to be proven, not claimed
Can you walk me through a real example of a cross-system issue you resolved, including how long it took and who coordinated the fix?
A specific example with a defined timeline, naming who was involved from the vendor's side and how the custodian was engaged, with enough operational detail to confirm the example reflects a systematic process rather than a one-time exception
A general assurance that these issues are rare or handled case by case with no specific example, or an example described in terms too vague to assess whether it reflects a repeatable process
A ticket moves between teams
How is a ticket tracked when it involves back-and-forth between your team and a custodian?
A single continuous ticket record that follows the issue through resolution even as it moves between teams, so the client does not have to re-explain the problem each time a new party gets involved
The ticket is effectively closed and reopened as it moves between the vendor and the custodian, requiring the client to restate the issue and context each time a new party becomes involved in the investigation
The Scenario Question That Exposes Whether Ownership Is Real
Most vendors will say, when asked directly, that they take ownership of cross-system issues. That answer costs nothing to give and is rarely tested during a sales process. The more revealing approach is to present a specific scenario and ask the vendor to narrate exactly what happens.
Describe the restriction scenario from the opening of this piece: an account restriction updated on the platform on Monday, a trade generated Wednesday that appears to violate it, and initial checks on both the platform and custodian sides that each come back clean.
Ask the vendor who picks up that ticket, what they do in the first hour, and what happens if their own investigation doesn't immediately reveal the cause.
A vendor with real ownership infrastructure will describe a specific internal process: an identified team that handles ambiguous cross-system tickets, a defined step for reaching out to the custodian directly rather than asking the client to do so, and a commitment to keep working the issue rather than closing it once their own system checks out clean.
A vendor without that infrastructure will describe the same scenario in terms of "escalating to the custodian" or "advising the client to reach out to their custodian."
That description carries the language of ownership while functioning, in practice, as a handoff back to the client.
This distinction matters most in exactly the moment it's hardest to evaluate calmly: during an active rebalancing cycle, when an unresolved cross-system issue is affecting live trades rather than a hypothetical account.
What to Ask Reference Clients About Cross-System Issue Resolution
A general reference call about support responsiveness will rarely surface this gap, because most support interactions never touch the platform-custodian boundary. A reference call focused specifically on that boundary will.
Ask reference clients:
Whether the firm has experienced an issue where it was initially unclear whether the platform or a custodian was at fault, and how the vendor handled that ambiguity in the first day or two
Whether the vendor proactively coordinated with the custodian directly, or whether the reference client's own team had to serve as the go-between
How long it typically took to reach resolution on an issue like that, compared to a straightforward platform-only issue
Whether the reference client ever had to repeat the same explanation to multiple parties because the ticket didn't carry forward cleanly between the vendor and the custodian
What the Difference Looks Like When It Actually Happens
Firms whose vendor takes real ownership of cross-system issues describe those situations as manageable, even when the underlying problem is complex:
The vendor's team drives the investigation and communicates directly with the custodian when needed
The client stays informed without having to coordinate between two separate support organizations
The issue gets resolved as one continuous process, regardless of where the root cause ultimately turns out to be
Firms without that ownership describe a different pattern:
The client becomes the relay point between the platform vendor and the custodian, restating the same problem to each and often receiving conflicting explanations from both
Resolution stretches out, driven less by the difficulty of the technical fix and more by the absence of any single party driving it forward
Operations teams learn to expect this pattern for certain types of issues and build informal workarounds, like manually double-checking restriction updates against custodial records after every change, that exist purely to compensate for a support gap that was never actually closed
Three Things to Confirm Before Committing to a Trading and Rebalancing Platform
A specific description of the internal team or role responsible for cross-system issues, and confirmation that this responsibility exists independent of which custodians are involved.
Evidence of direct working relationships between the vendor and your specific custodians, not just a general claim of broad custodian coverage.
Reference clients who can describe an actual cross-system issue they experienced, including how ownership played out and how long resolution took.
RIA Checklist: Evaluating Cross-System Support Ownership
Cross-boundary support ownership is one of the most operationally consequential and least evaluated support dimensions for RIAs running trading and rebalancing workflows across multiple custodians.
Use the checklist below during vendor evaluation or an internal platform review to confirm that cross-system ownership is a defined, verifiable commitment rather than something negotiated case by case.
Each row reflects a specific mechanism a firm should be able to see and confirm, not a general assurance.
Evaluation Area
What Strong Cross-System Support Looks Like
Ownership assignment
A specific internal team or role owns issues that could originate at either the platform or a custodian, rather than closing tickets once the platform side is confirmed clean
Custodian relationships
Established, direct working relationships with the custodians your firm uses, rather than coordination that depends entirely on the client relaying information
Response time commitments
Defined response times apply from the moment a ticket is opened, even before the root cause is identified as platform-side or custodian-side
Ticket continuity
A single ticket record follows the issue through resolution across teams, so the client is not required to re-explain the problem to each new party
Demonstrated track record
Specific, real examples of resolved cross-system issues, including timelines and who coordinated the fix
Escalation during live trading
A defined process for escalating cross-system issues that surface during an active rebalancing cycle, distinct from routine support requests
Explore Cross-Boundary Support Capability with Vestmark
Ready to evaluate whether your trading and rebalancing platform vendor has built genuine ownership of the platform-custodian boundary into their support model or relies on your operations team to fill that gap? Contact Vestmark to learn how our support model addresses cross-boundary issues for RIAs managing workflows across multiple custodians.
Key Takeaways
RIAs typically rely on a trading and rebalancing platform provided by one organization and custodial relationships provided by entirely separate ones, which creates a structural gap at the boundary between the two that standard support evaluations rarely test.
Data timing mismatches, restriction propagation gaps, cash and settlement discrepancies, and corporate action handling are the most common sources of issues that sit at that boundary, where both the platform and the custodian can appear correct in isolation.
The most revealing evaluation approach is presenting a vendor with a specific cross-system scenario and asking them to narrate exactly what happens in the first hour, rather than accepting a general claim that they take ownership of these issues.
Reference calls focused specifically on cross-system issue resolution, not general support satisfaction, are the clearest way to learn whether a vendor's stated ownership model holds up in practice. Firms whose vendor takes real ownership describe cross-system issues as manageable and resolved as one continuous process.
Firms without it describe becoming the relay point between two support organizations, often developing manual workarounds to compensate for a gap that was never closed.
Why do issues at the boundary between a trading platform and a custodian create a different support challenge than issues fully contained within the platform?
When a problem is fully contained within the platform, the vendor's support team can investigate and resolve it using systems they fully control. When a problem sits at the boundary with a custodian -- such as a data timing mismatch or a restriction that has not propagated correctly -- both the platform and the custodian can review their own systems independently and each conclude that their side is functioning correctly, leaving the actual cause unaddressed unless one party takes ownership of investigating the handoff between the two. The technical complexity of the fix is often lower than the coordination complexity of getting two separate organizations to work on the problem together, which is why clear ownership of that coordination is what determines resolution speed more than technical capability does.
How can an RIA test whether a vendor's cross-boundary support ownership is genuine before signing a contract?
Present the vendor with the specific restriction scenario from the opening of this blog: an account restriction updated on the platform that appears not to have been reflected in a trade, with initial checks on both the platform and custodian sides coming back clean. Ask the vendor to describe exactly what their team does in the first hour, including whether they contact the custodian directly or ask the client to do so. A vendor with genuine ownership infrastructure will describe a specific internal process and a defined point of contact with the custodian. A vendor without it will describe the situation in terms of escalating to or advising contact with the custodian, which sounds like ownership but functions as a handoff.
What should an RIA look for in a reference call to assess how a vendor handles issues involving both the platform and custodial data?
Ask reference clients directly whether they have experienced a situation where it was initially unclear whether the platform or a custodian was responsible, and how that ambiguity was resolved in the first 24 hours. The most useful signal is whether the reference client had to serve as the relay between the vendor and the custodian or whether the vendor coordinated directly, since that distinction reveals whether ownership is built into the support model or left to the client to manage. The reference client's ability to describe the situation specifically, with a timeline and an account of who did what, is itself evidence of whether the resolution was systematic enough to remember clearly.
What operational workarounds tend to develop at RIAs whose trading platform vendor does not take clear ownership of cross-boundary issues?
Common workarounds include operations staff manually cross-checking restriction updates against custodial records after every change, maintaining informal tracking of known data timing mismatches with specific custodians, and building internal escalation habits that route around the vendor's support desk because past experience suggests the vendor will point to the custodian rather than resolve the issue directly. These workarounds consume operations team capacity that would not be necessary if cross-boundary ownership were clearly defined in the support relationship, and they tend to accumulate gradually rather than appearing all at once, making the total cost of the support gap difficult to quantify.
Why does this issue matter more for RIAs than for broker-dealers evaluating similar trading and rebalancing platforms?
Broker-dealers frequently operate with a proprietary or closely integrated custody arm, which reduces the number of boundaries between the trading platform and custodial data. RIAs are structurally custodian-agnostic, often working across multiple custodians that are entirely separate organizations from their trading and rebalancing platform vendor, which means the platform-custodian boundary is a regular feature of daily operations rather than an occasional edge case. For RIAs, the quality of support at that boundary has a direct and ongoing effect on operational reliability in a way that does not apply to broker-dealers whose custody and trading infrastructure are more tightly integrated.