Identity and approvals for regulated operating environments
Identity & Approvals is the public expression of the authority layer inside Turing. It determines who can do what, under which conditions, with what approval path, and how that authority becomes part of the governed record.
01
What it is
How this layer fits the governed operating model.
In regulated finance, identity is not merely about login security. It is about authority, entitlements, delegation, segregation of duties, and the ability to demonstrate why a person or system was permitted to act in the first place.
Within the Turing platform, we often refer to this layer through Pangolin. The public point is broader: identity and approvals are part of the operating architecture, not an IT sidecar. They shape what the machine is allowed to do.
That becomes more important as workflows become more automated and more AI-assisted. If authority is ambiguous, everything downstream becomes harder to trust. If authority is explicit, approvals, evidence, and replay become much cleaner.
02
Capabilities
Operational capabilities
Capabilities are presented as operating surfaces, not as isolated feature checklists.
Role and Purpose-Aware Entitlements
Access is aligned to real operating roles and intended workflow purpose, not just broad user categories inherited from generic enterprise software.
Approval Conditions Attached to Action
Approvals matter most when they are tied to the action being attempted, the context around it, and the authority of the actor initiating it.
Delegation with Boundaries
Authority can be delegated in a controlled way, with the system able to preserve who delegated what and under which scope.
Segregation of Duties
Important control boundaries remain enforceable when incompatible functions are separated at the platform level rather than left as policy aspirations.
Identity Events in the Record
Material access and approval events contribute to the same governed operating story as execution, evidence, and resulting outcomes.
Aligned with Sector Products
Wealth, payments, and assurance surfaces inherit a stronger control posture when they rely on the same authority model beneath them.
04
Design Principles
System design choices that shape the runtime.
The design principles below show what this layer is optimised to preserve operationally, not just how it appears in a simplified presentation.
Authority is part of the product
If a platform can trigger consequential actions, identity and approvals are product concerns, not just enterprise IT concerns.
Approvals need structure
Approval trails become more defensible when they attach to canonical objects and governed actions rather than loose document workflows.
Control starts with clarity
The clearer the authority model, the easier it becomes to explain execution, evidence, and system behaviour to internal and external reviewers.
05
Related
Adjacent architecture and connected product surfaces.
These pages show how this layer sits inside the broader Turing system.
Next step
Discuss authority and approvals
Contact the team to see how identity, approvals, delegation, and evidence fit together inside the Turing operating model.