Permission Matrix

Overview

The permission matrix defines what each integration type can access and perform within DMTR. Permissions are scoped by resource (positions, participants, transfers) and action (read, write, admin). Use this matrix to understand capability boundaries and to request the correct scopes when provisioning credentials. Over-requesting scopes may delay approval; under-requesting limits functionality.

Permission model

The permission model uses OAuth scopes and API key scopes to control access. Scopes are hierarchical: broader scopes include narrower ones (e.g., positions:write implies positions:read). Integrations receive the minimum scopes required for their use case. Scope changes require re-authorization or credential re-provisioning. Audit logs track scope usage for compliance.

Matrix table

The matrix table maps integration types (research platforms, portfolio systems, fund admin, custody, lending, compliance) to allowed resources and actions. Research platforms typically have positions:read and registry:read; portfolio systems add positions:write for sync; custody and settlement require transfers:write and settlement:admin. Refer to the full matrix below for your audience tier.

Scope management

Scope management includes requesting new scopes (submit a scope request with justification), reducing scopes (re-provision credentials with narrower scopes), and scope expiration (some scopes expire and require re-approval). Use the DMTR dashboard or API to view current scopes and request changes. Scope changes may require security review for sensitive resources.