Governance
AI designed for accountable environments.
A model that cannot be explained, monitored, versioned and audited does not belong in a regulated institution. This page describes the constraints TasawurAI is being built against — not aspirations added afterwards, but requirements that shape the architecture.
- Decision
- Always a person
- Evidence
- Retained with every score
- Releases
- Validated and approved
- Record
- Reconstructable after the fact
Human judgment stays in the loop.
TasawurAI is a decision-support layer. It scores, explains and recommends; it does not act on a customer, close an account or make a determination. That boundary is a design constraint, not a limitation we intend to remove.
- 01
Model
Produces a score
- 02
Evidence
Retains what it used
- 03
Explanation
States it in reviewable terms
- 04
Analyst
Reads, investigates, judges
- 05
Decision
Recorded with its reason
The analyst is the decision-maker
Every alert is designed to reach an authorised person with the evidence attached. The platform's output is an input to their judgement.
Reasons travel with scores
A score arrives with the signals that produced it and the weight each carried, so it can be questioned rather than only accepted.
Outcomes are recorded
The decision, its reason code and the reviewer's role are retained with the case, which is what makes later review possible.
Principles the build is held to
Ten constraints that determine what gets implemented and what does not.
- 01
Explainability
Every risk score is designed to arrive with the signals that produced it and the weight each one carried, in language a reviewer can act on.
- 02
Human oversight
The platform is a decision-support layer. Investigation and the final decision remain with authorised bank personnel.
- 03
Auditability
Alerts, evidence, analyst actions and model versions are intended to be recorded as an immutable trail that can be reconstructed after the fact.
- 04
Role-based access
Access to cases, customer data and model controls is scoped to role, so investigation and model administration stay separated.
- 05
Model monitoring
Model performance is intended to be tracked continuously against live outcomes rather than assessed once at deployment.
- 06
Drift detection
Shifts in input distributions and in fraud behaviour are monitored, because a model's accuracy is a function of the world it was trained on.
- 07
Version control
Every model, feature set and rule configuration is versioned, so any historical decision can be tied to the exact logic that produced it.
- 08
Controlled updates
Model changes are designed to move through validation and institutional approval before they affect production decisions.
- 09
Data minimisation
The platform is designed to process the attributes detection requires, rather than to accumulate customer data by default.
- 10
Secure handling
Data protection is treated as an architectural constraint — deployment topology, access boundaries and retention are decided with the institution.
Controlled model updates
A model in a bank is not a piece of software that ships when it is ready. It is a change to how decisions are made, and it moves through validation and approval before it affects anything.
- DevelopFeatures and candidate models built against institution data
- ValidatePerformance, stability and bias assessed before release
- ApproveInstitutional sign-off recorded as part of the release
- DeployVersioned release, with the prior version retained
- MonitorLive performance and drift tracked continuously
- ReviewFindings and outcomes returned to the next candidate
No model reaches production without validation and institutional approval
Monitoring and drift
Model accuracy is a function of the world the model was trained on, and that world changes. Input distributions, feature stability and live outcome agreement are intended to be tracked continuously, so a decline in performance is detected by the system rather than discovered through a loss.
Versioning and reconstruction
Every model, feature set and rule configuration is versioned, and the version that scored an event is retained with the event. The intent is simple: any historical decision can be tied to the exact logic that produced it, months or years later.
Data handling and access
Detection requires customer data. That makes minimisation, boundaries and access control architectural questions rather than policy documents written after the fact.
Data minimisation
The platform is designed to process the attributes detection requires, rather than to accumulate customer data by default.
Role-based access
Case access, customer data and model administration are scoped separately, so investigation and model control are not the same permission.
Deployment boundary
Where processing happens is agreed with the institution. We do not assert that data must leave, or must remain within, any environment.
Retention
Retention periods for events, cases and evidence are configured to the institution's obligations, not to a product default.
Action trail
Alerts, evidence, analyst actions and model versions are intended to be recorded as an immutable trail.
Separation of duties
Model release and case decisioning are designed as distinct roles with distinct approvals.
Regulatory posture
We would rather understate our position than imply a status we do not hold.
TasawurAI is pursuing controlled validation through the Palestine Monetary Authority Regulatory Sandbox framework. Our proposed testing approach is structured around controlled validation, human oversight and regulatory alignment.
This describes our intended approach to testing. It is not a claim of approval, endorsement, certification or partnership by any regulator or supervisory authority.
What we do not claim
- No regulatory approval, endorsement or certification
- No security or compliance certifications
- No deployed customers or bank partnerships
- No detection accuracy, fraud-prevented or volume figures
- No published performance benchmarks
When any of these change, they will be stated here with the evidence behind them.
Built for accountable AI.
If you are assessing this from a risk, audit or supervisory position, we are happy to walk through the architecture in detail.