Swootle Book a demo

Trust and company services

Make the TCSP operating model visible from intake to refresh.

Connect TCSP client intake, entities, trusts, ownership, evidence, configured risk, human approval and refresh workflows with clear product boundaries.

A practical framework for TCSP leaders, MLROs, operations teams and implementation owners who need entity, trust, evidence, risk, approval and refresh work to stay connected.

For the people doing the work

Built around the questions a reviewer will ask later.

This page is for TCSP owners, MLROs, client-onboarding leads, reviewers and implementation teams. It describes configurable workflow support, not legal advice or a universal interpretation of beneficial ownership.

  • Complex entities and trusts
  • Evidence and follow-up
  • Risk and approval
  • Refresh design

Workflow is the thread between customer, structure, evidence and decision.

Point identity checks are useful inputs, but they do not by themselves explain who owns or controls a layered arrangement, why the service is being requested, what evidence was missing or why a reviewer accepted the remaining uncertainty.

A reusable framework

A TCSP onboarding lifecycle that can be adapted to the programme.

Use the sequence as a design conversation. The exact questions, evidence, thresholds, provider checks, reviewers and timing should come from your documented risk assessment and jurisdictional advice.

  1. Service triage
  2. Entity intake
  3. Ownership and control
  4. Evidence collection
  5. Return or complete
  6. Risk and approval
  7. Refresh and change

What the flow needs to carry

From returned information to an accountable decision.

Fit: Start with the service and the relationship

Capture the service requested, matter context, jurisdictions, introducer or intermediary role and the people who can instruct the firm. An industry label alone does not settle scope.

Structure: Represent entities, trusts, ownership and control

Use company, person and ownership-edge information to build the structure your reviewers need. Trust roles, authority and control questions remain configurable and jurisdiction-sensitive.

Evidence: Collect evidence with a clear reason

Ask for documents, declarations and returned check context through the customer journey. Set requirements by path, keep missing information visible and reopen or hand off when the submission is not complete.

Decision: Configure risk and keep a human approval step

Route based on the rules your programme defines, then give the reviewer the facts, evidence, checklist, comments and decision context needed to approve, return or escalate.

Operate: Design the next workflow for change and refresh

Identity refresh and ongoing review workflows can be configured around changed information and evidence. Swootle does not claim a native scheduler or continuous monitoring service, so confirm cadence and provider arrangements during implementation.

Improve: Version the operating model as the programme evolves

Use reusable templates, steps, versioning and publishing to keep the process understandable for staff. Test the workflow with representative synthetic cases before releasing changes.

Product responsibilities

Where Swootle helps, and where your programme still leads.

  • Configure: templates, steps, branches, versioning and publishing.
  • Collect: customer intake, entity and ownership information, document requirements and returned information.
  • Route: configured risk rules, review stages, roles, checklists, comments and approval decisions.
  • Retain context: connect submissions, evidence, reviewer action and the decision record.
  • Verify: available checks and integrations depend on the configured provider arrangement. Do not assume native PEP, sanctions, adverse-media, EDD, scheduler or named-system coverage.

Customer portal →

Risk and review →

Security →

Implementation questions

Prove the workflow with representative cases before release.

  1. Map services, customer types, entities, trusts, roles, jurisdictions and approval owners.
  2. Define evidence requirements and the path when information is missing, inconsistent or returned for update.
  3. Configure risk inputs and reviewer actions without presenting a rule result as a legal conclusion.
  4. Run synthetic files through happy paths, complex structures, exceptions and refresh scenarios.
  5. Agree how changes are versioned, published, monitored and reviewed with your legal or compliance adviser.

Read the canonical TCSP buyer guide.

Resources and next step

Turn the framework into a workflow your team can inspect.

Browse the related product responsibilities and market context, compare the current proposal inputs or bring a real TCSP operating model to a walkthrough. Swootle supports configuration and decision context. Your team and advisers remain responsible for the programme and legal interpretation.