A control is only useful if the system can prove it operated.

The controls layer should connect policies, roles, rules, decisions, breaches, exceptions, and reviews to the lifecycle events they govern.

• Evidence, not policy alone

  Financial firms do not only need policies. They need evidence that policies were applied. That evidence has to answer practical questions about what action occurred, who performed it, what control applied, what decision was made, who reviewed it, what changed afterward, and whether the package can be produced for review, examination, ODD, or audit.

• Embedded in post-trade work

  Devancore is not a compliance module added after the operational system. It is a controls layer embedded in post-trade work. System of Record provides canonical participants, instruments, accounts, SSIs, positions, and source data. Trade Lifecycle produces the state transitions. Finance & Reporting reads the evidence for regulatory, management, investor, and audit workflows. Connectivity brings external messages and rail events into the same evidence model. Controls make the operating record defensible.

Sensitive actions need role separation and review evidence by design.

Maker-checker, role-scoped access, participant-level authority, temporary access, and segregation of duties should be enforced through workflow, not informal procedure.

• Maker-checker as operating control

  Maker-checker is simple in principle: one user proposes, another authorized user reviews. In production operations, the hard part is making sure the second review is real, qualified, timely, and preserved. A material action can create a pending state. The checker decision can approve, reject, request repair, or escalate. The evidence should preserve the actor, role, source, timestamp, affected record, previous state, proposed state, decision, and reason.

• Functional separation, not role sprawl

  RBAC should be framed around functional separation: operations, compliance, supervision, finance, administration, read-only review, and participant-level authority should not collapse into one overpowered user. Temporary access also needs evidence. If a user receives elevated authority for an incident, vacation cover, market event, or operational emergency, the grant, reason, valid period, granter, revocation, and review should be visible. Access drift is a control problem. The system should make it observable.

• Supported, not absolute

  Devancore supports role-scoped access, self-approval prevention patterns, maker-checker review, and auditable access changes. It does not claim to prevent every unauthorized action.

Restrictions need timing, severity, source, and resolution evidence.

Investment guidelines, restricted instruments, watch lists, concentration limits, counterparty limits, liquidity rules, currency exposure, and custom firm policies should attach to accounts and lifecycle events.

• Rules are not all the same

  Some rules should block before action. Some should warn and require approval. Some should detect after execution. Some should run at end of day. Some should run continuously. Some are hard constraints. Some are soft limits. Some are watch conditions. Some are evidence triggers.

• Rules become operating evidence

  A rule result should not be a transient message on a screen. It should connect to the account, instrument, position, trade, counterparty, source, threshold, breach value, reviewer, remediation, exception justification, and closure state. Asset managers need guideline monitoring. Broker-dealers need supervisory evidence. Digital asset firms need wallet, counterparty, and transfer controls. The underlying pattern is the same: rule, event, evidence, review.

Sanctions and market controls need source evidence, not unsupported legal conclusions.

Devancore connects entity, market, country, currency, CSD, tax, sanctions-source, watchlist, and restricted-list evidence to the operating record while leaving legal determinations to the firm.

• Source infrastructure, precise language

  Devancore's market data work includes country identity, ISO currency data, MIC market identifiers, CSD and source discovery, tax profile source layers, FATCA source files, and U.S. screening-list extracts from the ITA Consolidated Screening List with OFAC, BIS, and State source flags. These sources support screening, classification, routing, reporting, workflow, and evidence. They do not by themselves determine whether a transaction is legally permitted.

• Source-linked review

  Devancore can help attach source evidence to the record being reviewed. A counterparty screening result should connect to the counterparty. A restricted instrument alert should connect to the instrument and account. A country or market restriction should connect to the jurisdiction, market, and trade. A sanctions-source alert should open or support a review workflow with source, timestamp, list, matched field, reviewer, decision, and disposition. Devancore supports screening workflow evidence and source-linked review. It does not clear sanctions or automate AML compliance.

A breach is not finished when someone notices it. It is finished when the evidence shows what happened and why it closed.

Control breaches, warnings, exceptions, remediation steps, supervisory approvals, and WSP evidence should move through one documented lifecycle.

• Breach lifecycle management

  A mature control system does not only detect breaches. It manages them with state, ownership, evidence, and resolution through detection, investigation, acknowledgment, remediation, exception approval, escalation, and closure.

• Supervisory evidence layer

  FINRA Rule 3110 is about supervisory systems and procedures. Rule 3120 adds supervisory control system review. WSPs are valuable when the firm can map procedures to operating evidence. Devancore helps produce the operating evidence that WSPs and supervisory reviews need: maker-checker events, principal sign-offs, breach investigation history, exception approvals, access-change approvals, case escalations, and closure decisions. Devancore does not write WSPs or guarantee supervisory compliance.

Examination evidence should be assembled from the work itself.

FINRA examinations, SEC record reviews, operational due diligence, audits, and internal reviews need source-linked evidence packages, not after-the-fact reconstruction.

• Evidence generated by operations

  The audit trail should be generated by operations. The platform may use append-only event history and preservation controls designed to support books-and-records workflows. Devancore helps preserve source-linked event evidence and supports retrieval for review. Rule 17a-4 depends on storage configuration, indexing, access, retention, production capability, undertakings where applicable, administrative controls, and the firm's supervisory framework.

• Ops Copilot boundary

  If Ops Copilot is included, its role is explain-only, read-only, and logged. It may draft a narrative from event history or summarize case evidence. It must not approve controls, decide compliance outcomes, file regulatory responses, or replace compliance review.

• Operational facts, not paperwork

  Controls are not paperwork. Controls are operational facts that can be produced when asked.

Controls connect policy, operations, markets data, supervision, and evidence.

Use these pages to move from controls into canonical records, lifecycle workflows, security architecture, regulatory context, use cases, and glossary definitions.