Service Responsibility Matrix for a Brokerage Project

Use tasks that can be handed over

Replace a row called compliance with separate tasks: maintain onboarding policy, collect documents, investigate an exception, authorize a decision and retain evidence. Replace platform management with account provisioning, permission changes, release management, monitoring and incident escalation. The more concrete action makes a missing owner easier to identify.

NIST's supplier guidance recommends explicit responsibilities and communication across organizations. A matrix can use responsible, accountable, consulted and informed roles, but the labels matter less than a clear decision owner and workable handoff. Avoid assigning approval to a generic team mailbox without identifying who has authority when the task becomes urgent.

Separate technology control from legal authority

A software supplier may configure forms or screening interfaces, while the operator owns its policy and decisions under applicable requirements. A hosting company may maintain infrastructure without controlling account-opening decisions. MetaQuotes describes its role as software development, not the provision of investment or brokerage services; platform access therefore cannot stand in for the operator's permissions.

Determine the legal responsibilities for the actual entities, activities and markets through the appropriate qualified review. A commercial responsibility matrix cannot transfer a statutory duty simply by placing another supplier's name in a cell. Record dependencies on approvals and keep client-facing claims consistent with the arrangement actually established.

Test handoffs and exceptions

Walk through a normal case and a failure case. Who receives a duplicate-payment alert, who can stop affected automation, who reconciles the ledger and who authorizes reopening? Ask the same questions for a platform outage or a changed client-risk finding. Capture required inputs and proof of completion for each handoff.

AWS's shared-responsibility model is a useful example of boundaries changing with the selected service. Your matrix must follow the actual stack and agreements. Review it when a supplier, deployment model, permission set or business activity changes. Keep a version and acceptance record so every party can see which responsibilities were agreed.

Example: an onboarding exception crosses three roles

In a fictional deployment, a technology supplier maintains document-upload availability, a screening provider returns assessment data and the operator's authorized reviewer decides the case. If the upload fails, the technology supplier investigates. If the returned identity data conflicts, the reviewer follows the operator's escalation process. A successful API response does not authorize the customer to trade.