Zero-Tolerance Rules

Take every rule below seriously. Breaking one is never a small thing. The harm can run from heavy financial loss to lasting damage to our reputation, and at worst it could be enough to sink the company. Many of these rules are what keep attackers out, so breaking one can be the very gap someone uses to get in and hack us. Some of these rules also reflect the law, so breaking them could land you, or Finperiti, in real trouble with the authorities. That is why they should never be broken. We are not setting them out to catch you out, but to make the hard lines clear so you are never left guessing where they fall.

These are the rules you can be dismissed for breaking — and, depending on the harm, potentially even personally prosecuted. So please don't break them. They are gathered here, in one place, from across the guidelines, so there is no doubt about where the hard lines are. "Zero tolerance" means exactly that. No deadline, no instruction from anyone, no "just this once", and no "it was only internal" makes a single one of them acceptable.

One line is worth stating up front, because it is easy to get wrong with the best of intentions: never assume that everyone who works for a customer is trusted equally. A customer's own staff hold different roles and have different need-to-know, so always enforce proper access control on every action, rather than wave someone through because they belong to the right organisation.

223 zero-tolerance rules across 95 area(s). Each links back to its full topic.

Designing for Failure (Fail-Closed)

• Zero ToleranceNever fail open. When something is missing, unknown, or uncertain, deny or escalate. Never default to the permissive outcome.
• Zero ToleranceNever auto-approve a customer, transaction, or onboarding when a screening, sanctions, or KYC check is missing, errored, timed out, or unrecognised. Block and escalate.
• Zero ToleranceNever let a failure in a non-critical dependency silently disable a critical control such as screening. Surface it and fail closed.

Trust Boundaries & Input Validation

• Zero ToleranceNever act on an inbound webhook or third-party callback without first verifying its signature or authenticity.
• Zero ToleranceNever build SQL, shell commands, file paths, or markup by joining unvalidated input as strings. Use parameterised queries and safe APIs.

Authentication & Authorization

• Zero ToleranceNever expose an endpoint that touches PII, money, or regulated data without authentication, or ship an auth bypass (for example [AllowAnonymous]) on a protected route.
• Zero ToleranceNever trust identity, role, or tenant sent in the request body, query string, or a client-set header. Derive it server-side from the validated token.
• Zero ToleranceNever query, update, or delete tenant-owned data without enforcing the tenant predicate, or let a user grant themselves a role or raise their own privileges.

Multi-Tenancy & Data Isolation

• Zero ToleranceNever query, update, or delete tenant-owned data without enforcing the tenant predicate server-side. No cross-tenant access, ever.
• Zero ToleranceNever use a single shared signing key or trust boundary that lets one tenant's identity be valid for another's data.

Concurrency & Shared State

• Zero ToleranceNever do a money- or balance-changing read-modify-write without concurrency control. Last-writer-wins on a balance loses money.

Security Essentials

• Zero ToleranceNever share an account, login, or password between people/actors. Every actor — human, AI, or service — must have its own identity.
• Zero ToleranceNever use a personal account (personal email, personal cloud, personal device credentials) to access, store, or process company or customer data.
• Zero ToleranceNever disable, bypass, or "temporarily" skip multi-factor authentication on any account with access to systems or data.
• Zero ToleranceNever keep a leaver's, contractor's, or unused account active. Access ends when the need ends.
• Zero ToleranceNever commit a secret to source control — API keys, connection strings, certificates, account keys, client secrets. Not even for a moment, and not even in a private repo.
• Zero ToleranceNever store secrets in plaintext — in config files, environment files, IaC state, database columns, or logs.
• Zero ToleranceNever hard-code a secret in application code, tests, or pipeline definitions.
• Zero ToleranceNever send a credential, token, key, or password over email, chat, SMS, ticket, screenshot, or any messaging tool — for any reason. Share access only through the approved secret store / vault.
• Zero ToleranceNever reuse one secret across environments (dev/test/prod) or across services.
• Zero ToleranceNever leave a known-exposed secret in place. A secret that was committed or shared is compromised. Rotate it at once and treat it as a breach.
• Zero ToleranceNever expose an endpoint that touches PII, money, or regulated data without authentication.
• Zero ToleranceNever trust an identity, role, or tenant that comes from the request body, query string, or a client-set header. Take the identity from a validated token, on the server.
• Zero ToleranceNever ship [AllowAnonymous] (or any auth bypass) on a protected route — default-deny is the baseline.
• Zero ToleranceNever query, update, or delete tenant-owned data without enforcing the tenant filter on the server. Never allow access across tenants.
• Zero ToleranceNever let a user give themselves a role or raise their own privileges through an unguarded create or update path.
• Zero ToleranceNever assume a customer's own employees are all trusted equally. Staff inside one tenant hold different roles and need-to-know, so enforce a role and least-privilege check on every action, not only a tenant boundary at the edge.
• Zero ToleranceNever build SQL, shell commands, file paths, or markup by joining together unvalidated input. Use parameterised queries and safe APIs.
• Zero ToleranceNever act on an inbound webhook or third-party callback before you verify its signature and that it is genuine.
• Zero ToleranceNever trust a value just because it came from your own database or another internal service. Stored data is still input, and you must validate it.
• Zero ToleranceNever disable TLS/certificate validation or run RequireHttpsMetadata=false against anything outside local dev.
• Zero ToleranceNever store passwords in a form you can recover. Use a per-user salted, memory-hard hash. Never compare or return a plaintext password.
• Zero ToleranceNever log secrets, credentials, tokens, full PII, or special-category data.
• Zero ToleranceNever return internal details (stack traces, SQL, secrets, file paths) to an external caller.
• Zero ToleranceNever store special-category or cardholder data we do not need. If we must hold it, encrypt it at rest.
• Zero ToleranceNever hard-delete regulated records (customer, KYC, AML, audit, SARs). Use a soft-delete, with a role check, tenant scope, and an audit entry.
• Zero ToleranceNever fail open. When something is missing, unknown, or uncertain, deny it or escalate to a human. Never default to allowing it.
• Zero ToleranceNever hide a security-relevant error or skip a check to "make it work".
• Zero ToleranceNever perform a destructive or risk-changing operation without an audit record that cannot be changed, showing who did it and when.
• Zero ToleranceNever weaken a security control to meet a deadline. Raise the trade-off. Do not decide it on your own.
• Zero ToleranceNever auto-approve a customer, transaction, or onboarding when a screening, sanctions, PEP, or KYC check is missing, errored, timed out, or returned a result you do not recognise. The safe default is to block and escalate. Never approve.
• Zero ToleranceNever treat an unknown or unmapped input (country, industry, document type, risk band) as low or medium risk. Unknown means escalate.
• Zero ToleranceNever disable, bypass, or weaken a screening or monitoring control — including the screening kill-switch — without authorisation and a permanent audit record.
• Zero ToleranceNever hide, edit, or delete a Suspicious Activity Report, an alert, or any required AML/KYC evidence. Regulated evidence can only be added to, never changed.
• Zero ToleranceNever ship an automated decision that controls access to financial services without the required human-oversight and explainability controls in place.
• Zero ToleranceNever deploy to production by hand or outside the normal process. All production changes go through the pipeline, with the security and quality gates enforced, not bypassed.
• Zero ToleranceNever merge or release code that has not passed the automated security checks (secret scanning, dependency/vulnerability scan, SAST). A failing gate is a stop, not a warning.
• Zero ToleranceNever make a change directly in the production database or environment without change control, review, and an audit trail.
• Zero ToleranceNever copy production data — especially PII, KYC, or AML data — into a development, test, or personal environment. Use synthetic or properly masked data.
• Zero ToleranceNever grant standing production access "to be efficient". Access is least-privilege, time-limited, and logged.

Security by Design

• Zero ToleranceNever trust the client. Identity, role, tenant, price, and permission are decided on the server from a validated token, never from anything the caller can set.
• Zero ToleranceNever weaken or remove a security control to meet a deadline or unblock a demo. Raise the trade-off and make it an owned decision, never a silent one.

Secure Defaults & Hardening

• Zero ToleranceNever disable TLS/certificate validation, or run RequireHttpsMetadata=false, against anything outside local development.
• Zero ToleranceNever make a route anonymous, widen CORS to all origins, or weaken a security default to "unblock" something, unless that change is reviewed and owned.

Identity & Account Hygiene

• Zero ToleranceNever share an account, login, or password between people/actors. Every actor — human, AI, or service — must have its own identity.
• Zero ToleranceNever use a personal account or personal device credentials to access, store, or process company or customer data.
• Zero ToleranceNever disable, bypass, or "temporarily" skip MFA on any account with access to systems or data.
• Zero ToleranceNever keep a leaver's, contractor's, or unused account active. Access ends when the need ends.
• Zero ToleranceNever grant standing production access "to be efficient". Access is least-privilege, time-limited, and logged.

Cryptography & Key Management

• Zero ToleranceNever store passwords in a form you can recover, or compare or return them in plaintext.
• Zero ToleranceNever use a single shared symmetric secret across tenants or services to sign tokens. A leak, or a malicious verifier, then becomes a forger.
• Zero ToleranceNever reuse one key across environments or services, or leave a known-exposed key in place. A leaked key is compromised. Rotate it at once and treat it as a breach.

Secrets at Rest & in Transit

• Zero ToleranceNever commit a secret to source control — keys, connection strings, certificates, client secrets. Not even for a moment, and not even in a private repo.
• Zero ToleranceNever store secrets in plaintext — in config files, env files, IaC state, database columns, or logs.
• Zero ToleranceNever hard-code a secret in application code, tests, or pipeline definitions.
• Zero ToleranceNever send a credential, token, key, or password over email, chat, SMS, ticket, or screenshot. Share access only through the approved vault.
• Zero ToleranceNever reuse one secret across environments or services, or leave a known-exposed secret in place. Rotate it at once and treat it as a breach.

Session & Token Management

• Zero ToleranceNever accept a token without verifying its signature, issuer, audience, and expiry, or honour the alg: none / algorithm-confusion family.
• Zero ToleranceNever trust an identity, role, or tenant from the request body, query string, or a client-set header instead of the validated token.
• Zero ToleranceNever issue tokens that effectively never expire, or have no way to revoke a session once it is issued.

Dependency & Supply-Chain Security

• Zero ToleranceNever merge or release code that has not passed automated dependency/vulnerability and secret scanning. A failing gate is a stop, not a warning.
• Zero ToleranceNever knowingly ship into production a dependency with an unfixed serious vulnerability, or an end-of-life library, without a documented, time-bound remediation plan.

Identity Provider & SSO (Entra ID / OIDC)

• Zero ToleranceAlways authenticate through the standard identity provider (Entra ID) using OpenID Connect / OAuth 2.0 and the official libraries (MSAL). Do not build your own login or token-issuing scheme.
• Zero ToleranceNever roll your own authentication, token format, or session scheme, or sign tokens with a single shared symmetric secret, for anything handling real users or data.
• Zero ToleranceNever disable issuer, audience, signature, or expiry validation, or accept tokens from an untrusted issuer.

Vulnerability Management & Penetration Testing

• Zero ToleranceNever knowingly ship or leave a known serious vulnerability in production without a documented, time-bound remediation plan and an owner.

Web & Frontend Security

• Zero ToleranceNever pass untrusted content to dangerouslySetInnerHTML, innerHTML, or an equivalent without sanitising it first. That is a direct XSS hole.
• Zero ToleranceAlways enforce every authorisation and validation rule on the server. The client is for convenience and UX, never for security. Hiding a button is not access control.
• Zero ToleranceNever put secrets, API keys, or other users' data into client-side code or the page. Anything the browser receives, the user — and an attacker — can read.

File Uploads & Handling

• Zero ToleranceNever run uploaded content, or let the browser run it. Store it as data, serve it with a safe content-type and Content-Disposition: attachment, and never from a path that runs code.
• Zero ToleranceNever serve user uploads from the same origin as the app without a safe content-type and a download disposition. A malicious HTML/SVG upload can run as script in the user's session (stored XSS).

AI & LLM Feature Security

• Zero ToleranceNever let model output directly trigger an important or irreversible action (payment, data change, access grant) without validation and, for regulated decisions, human oversight.

Database Design & Schema

• Zero ToleranceNever store special-category or cardholder data we do not need. If we must hold it, encrypt it at rest and tighten access at the column level.
• Zero ToleranceNever make a schema change directly in production without change control, review, and a migration (see Schema Versioning).

Schema Versioning & Migrations

• Zero ToleranceNever edit a migration that has already run in a shared environment. Write a new one instead. Rewriting history corrupts state.
• Zero ToleranceNever hard-delete or drop columns or tables holding regulated data without confirming retention obligations and taking an audited backup.

Data Integrity & Transactions

• Zero ToleranceNever make a money or regulated-state change as a series of independent writes that can partly fail and leave an invalid state.
• Zero ToleranceNever retry a non-idempotent operation (a charge, a transfer, a state transition) without a guard. A retried payment is a duplicate charge.

Data Modelling & Persistence

• Zero ToleranceNever build SQL by concatenating unvalidated input, or query tenant-owned data without enforcing the tenant predicate server-side.

Data Protection & Privacy

• Zero ToleranceNever copy production personal, KYC, or biometric data into dev, test, or personal environments — use synthetic or masked data.
• Zero ToleranceNever store special-category data without a valid lawful basis, or in a way that lets it cross tenant boundaries.

Secrets Management

• Zero ToleranceNever commit, hard-code, or store secrets in plaintext config, env files, or source. Share access only through the vault.
• Zero ToleranceNever reuse one secret across environments or services, or leave a known-exposed secret in place. Rotate it and treat it as a breach.

Audit Trails & Traceability

• Zero ToleranceNever perform a destructive or risk-changing operation without an immutable audit record, or edit or delete statutory AML or KYC evidence.

Data Classification & Handling

• Zero ToleranceNever log Restricted data (special-category, secrets, full PII), return it in an API response, or send it to an external service (see Observability & Logging Hygiene).
• Zero ToleranceNever copy production Confidential or Restricted data into dev, test, or personal environments. Use synthetic or masked data (see Test Data & Environments).

File & Blob Storage

• Zero ToleranceNever make a container or file holding personal or KYC data publicly accessible, or reachable by a guessable URL.

Data Masking & Redaction

• Zero ToleranceNever send full special-category, card, or secret values to a client, log, analytics tool, or non-production environment when a masked or tokenised form would do.

Reporting & Data Exports

• Zero ToleranceAlways scope every report and export to the requester's tenant and authorisation. A report must never include data the requester is not entitled to (see Multi-Tenancy, Authentication & Authorization).
• Zero ToleranceNever generate an export containing personal or special-category data without access control, tenant scoping, and awareness of where the file then goes (see Handling; exports are an easy breach).

Search & Indexing

• Zero ToleranceAlways scope every search to the user's tenant and authorisation. Results must only ever include data the searcher is entitled to see, enforced server-side (see Multi-Tenancy, Authentication & Authorization).
• Zero ToleranceNever return search results across tenant boundaries, or expose an index publicly or too permissively (a classic source of data leaks).

Data Pipelines & ETL

• Zero ToleranceNever copy production personal or KYC data into a non-production or lower-trust destination through a pipeline without masking and authorisation (see Test Data & Environments).

API & Contract Design

• Zero ToleranceNever trust identity, role, tenant, or price from the request body or a client-set field. Derive privileged values on the server.
• Zero ToleranceNever return internal details (stack traces, SQL, secrets, file paths) in an API response to an external caller.

Third-Party Integrations & Resilience

• Zero ToleranceNever act on an inbound webhook or third-party callback before you verify it is genuine.
• Zero ToleranceNever auto-approve a customer or transaction when a provider check is missing, failed, timed out, or returned a result you do not recognise.

Asynchronous Messaging & Eventing

• Zero ToleranceNever process a non-idempotent message that changes money or state without a guard against duplicate delivery.

Email & Notifications

• Zero ToleranceNever email secrets, passwords, full card or account numbers, MFA codes, or special-category data. Share access through the secure app, not the inbox (see Secrets at Rest & in Transit).

Outbound Webhooks

• Zero ToleranceNever put secrets, full PII, or special-category data in a webhook body. Send a reference and let the receiver fetch it over an authorised API (see Data Classification).

Partner API Access & API Keys

• Zero ToleranceNever issue a shared, long-lived, all-powerful key, or send or store a partner secret in plaintext. Share it through a secure channel and store only a hash.
• Zero ToleranceAlways enforce that a partner can only access its own data. Derive the tenant or partner from the validated credential, never from a request parameter (see Multi-Tenancy).

Frontend Architecture & Components

• Zero ToleranceAlways enforce every security, authorization, and validation rule on the server. The client may mirror it for UX, but it must never be the only check (see Authentication & Authorization).
• Zero ToleranceNever put secrets, other users' data, or trust decisions in client-side code. The user can read everything shipped to the browser (see Web & Frontend Security).

Real-Time & WebSockets

• Zero ToleranceNever send data to a user on a real-time channel without confirming that connection is authorised for it. Open connections are an easy place to leak data across users or tenants.

Azure & Cloud Platform

• Zero ToleranceNever deploy regulated or personal EU data to a region that breaches residency obligations.
• Zero ToleranceNever expose a database, storage account, or admin surface to the public internet, or store secrets in app configuration instead of Key Vault.

Infrastructure as Code (Pulumi)

• Zero ToleranceAlways provision and manage all infrastructure through Pulumi in source control. Every resource, role, and network rule is versioned code, deployed via CI/CD. The only exception is purely experimental, throwaway resources that never touch real data or production.
• Zero ToleranceNever make production infrastructure changes by hand in the portal, outside IaC and change control.
• Zero ToleranceNever hold or use standing direct edit or write access to deployed infrastructure (portal, CLI, or console). Changes go through Pulumi and CI/CD. Direct access causes drift and bypasses review. Break-glass access is the rare, time-bound, audited exception.
• Zero ToleranceNever commit secrets, connection strings, or keys into IaC source or unencrypted state.

Managed Identity & Least-Privilege Access

• Zero ToleranceNever use a stored connection string, account key, or API key where a managed identity would work, or commit such a credential to config or code.
• Zero ToleranceNever grant standing, broad, or production admin access "to be efficient". Access is least-privilege, scoped, time-bound, and logged.

Network & Resource Isolation

• Zero ToleranceNever expose a database, cache, storage account, or admin/management surface to the public internet.
• Zero ToleranceNever connect a non-production environment to production data or networks, or copy production data across that boundary.

Containers & Images

• Zero ToleranceNever bake secrets, keys, or credentials into an image or its layers. They stay in the history even if you delete them later. Inject them at runtime from the vault or managed identity.

Container Orchestration

• Zero ToleranceNever make production cluster changes by hand outside IaC and CI/CD. It causes drift and bypasses review (see Infrastructure as Code).

Observability & Logging Hygiene

• Zero ToleranceNever log secrets, credentials, tokens, full PII, or special-category data.
• Zero ToleranceNever return internal details (stack traces, SQL, secrets, file paths) to an external caller. Diagnostics go to logs, not to the response.

Configuration

• Zero ToleranceAlways source secrets from the vault via the secure workflow, never from configuration files (see Secrets at Rest & in Transit).
• Zero ToleranceNever commit secrets, connection strings with passwords, or keys into configuration files or source control.

CI/CD & Deployment

• Zero ToleranceAlways treat a failing security or quality gate as a stop to be fixed. Never bypass, skip, or override it to ship.
• Zero ToleranceNever merge or release code that has not passed the automated security and quality checks.
• Zero ToleranceAlways run database migrations through the pipeline as part of the deploy, reviewed and reversible in intent, not by hand.
• Zero ToleranceNever deploy to production by hand or outside the pipeline, or change the production environment directly without change control and an audit trail.

Incident Readiness

• Zero ToleranceAlways have a way to recognise and escalate a security or personal-data breach, because it starts a regulatory notification clock measured in hours.
• Zero ToleranceAlways preserve the audit trail and evidence during incident response. Record what was done and when, and never destroy regulated evidence in the rush.
• Zero ToleranceNever hide, downplay, or fail to escalate a security or data-breach incident. Concealment turns a manageable event into a regulatory and trust catastrophe.

Backup, Recovery & Business Continuity

• Zero ToleranceAlways restore regulated records (KYC, AML, audit, SARs) intact and keep them within their required residency and retention. Recovery must not become a quiet data loss.

Security Monitoring & Detection

• Zero ToleranceNever disable or bypass security logging or alerting, or strip the audit or detection from a sensitive action, without authorisation and a record.

Deployment Strategies (Canary, Blue-Green)

• Zero ToleranceNever deploy by hand outside the pipeline, or skip the health checks or rollback path to push something out quickly (see CI/CD & Deployment).

Background Jobs & Scheduled Work

• Zero ToleranceNever run a non-idempotent money- or state-changing job without a guard against duplicate or overlapping runs.

Caching Strategy

• Zero ToleranceAlways include the tenant (and user or role where relevant) in the cache key for any tenant- or user-scoped data. A tenant-blind key can leak data across customers.
• Zero ToleranceNever cache personalised or tenant-scoped responses under a shared key, or at a shared layer (CDN or proxy) that could serve them to the wrong user.

ML Model Operations (MLOps)

• Zero ToleranceAlways fail closed on low-confidence, missing, or errored model output: block and escalate to a human, never auto-approve (see Designing for Failure, AML Screening).
• Zero ToleranceNever let a model be the only, unchecked gate on a regulated decision, or deploy one without the evaluation, monitoring, and oversight controls in place.

Trunk-Based Development, TDD & Pairing

• Zero ToleranceNever merge to trunk before the change has been reviewed, either by a pair in real time or by a fast async review, and before it passes the automated gates.

Testing Strategy

• Zero ToleranceNever copy production data, especially PII, KYC, or AML data, into tests or fixtures. Use synthetic or masked data.

Code Review

• Zero ToleranceNever approve a change you do not understand, or merge code that has not passed review and the automated security and quality checks.

Documentation as Code

• Zero ToleranceNever put secrets, credentials, tokens, or real customer/PII data into documentation, comments, READMEs, or examples.

Technical Debt

• Zero ToleranceNever take on "debt" by weakening a security or compliance control. A skipped fail-closed check, missing tenant scope, or absent audit trail is a vulnerability, not a shortcut.

AI-Assisted Development

• Zero ToleranceAlways take personal responsibility for AI-generated code as if you wrote it. Review it, understand it, and verify it before it ships.
• Zero ToleranceNever merge AI-generated code you do not understand, or trust it for security or compliance-critical logic without careful verification.
• Zero ToleranceNever put customer data, PII, secrets, credentials, or confidential code into a prompt or context sent to an external AI service.

Test Data & Environments

• Zero ToleranceNever copy production personal, KYC, AML, or payment data into dev, test, staging, or a personal environment.
• Zero ToleranceNever connect a non-production environment to production data or networks.

Version Control Hygiene (Git)

• Zero ToleranceNever commit secrets (keys, passwords, connection strings, tokens, certificates) to any repo, even briefly or in a private one. If you do, treat it as compromised: rotate it and tell security (see Secrets at Rest & in Transit).
• Zero ToleranceNever commit real customer or personal data (fixtures, dumps, screenshots) into the repository (see Test Data & Environments).

Bug Triage & Issue Management

• Zero ToleranceNever quietly ignore, hide, or close without fixing a known security or compliance bug to make the numbers look better (see Professional Ethics).

Hypothesis-Driven Development

• Zero ToleranceNever experiment on or weaken a compliance, security, or fairness control. For example, do not A/B test whether to skip a KYC step. These are not things we bet with.

A/B Testing & Experiments

• Zero ToleranceNever A/B test or experiment on a compliance, security, or fairness control. For example, do not test whether skipping a KYC or screening step boosts conversion. These are never things to optimise (see AML Screening, Hypothesis-Driven Development).

Professional Ethics & Integrity

• Zero ToleranceNever falsify, fabricate, or misrepresent data, test results, audit records, or the status of compliance controls.
• Zero ToleranceNever misuse access to customer data, systems, or insider information for personal gain, curiosity, or any purpose outside your job.
• Zero ToleranceAlways put honesty above pride. Embarrassment, fear of looking bad, or any habit of "saving face" does not override the duty to tell the truth here. This is a professional standard everyone follows, whatever their background or seniority.
• Zero ToleranceNever lie, cover up, or create a false impression to protect your reputation, avoid blame, or save face. This includes lying by leaving things out, giving vague non-answers, or claiming something is done, tested, or checked when it is not.
• Zero ToleranceNever blame someone else, or let a false account stand, to move attention away from your own mistake.
• Zero ToleranceNever knowingly build, ship, or hide something designed to deceive users, evade regulators, or cause harm.

Ownership & Accountability

• Zero ToleranceNever hide, downplay, or lie about a mistake to save face. The deal works both ways: honest mistakes are safe here, but hiding one is a serious breach of trust (see Professional Ethics & Integrity).

Respect, Inclusion & Belonging

• Zero ToleranceNever take part in harassment, discrimination, bullying, or demeaning behaviour. It is never acceptable and is a serious matter (see Professional Ethics; staff: Respect at Work).

Technical Writing

• Zero ToleranceNever put secrets, credentials, or real customer or PII data into docs, messages, tickets, or examples (see Observability & Logging Hygiene).

Compliance & Regulatory by Design

• Zero ToleranceNever ship a feature that processes regulated data in a way you cannot evidence as compliant, or in a region that breaches residency obligations.
• Zero ToleranceNever suppress, edit, or delete statutory evidence (SARs, alerts, audit, KYC/AML records). Regulated evidence is append-only.

Privacy & Data Protection (GDPR)

• Zero ToleranceNever process special-category data without a valid lawful basis, or expose it across tenant boundaries.
• Zero ToleranceNever copy production personal data, especially PII, KYC, or biometric data, into dev, test, or personal environments. Use synthetic or properly masked data.
• Zero ToleranceNever retain personal data with no defined purpose or retention limit, "just in case".

Data Retention & Erasure

• Zero ToleranceNever retain personal data indefinitely or with no defined retention rule.
• Zero ToleranceNever hard-delete regulated records (customer, KYC, AML, audit, SARs). Soft-delete with a role gate, tenant scope, and an audit entry.

Auditability & Evidence

• Zero ToleranceNever perform a destructive or risk-changing operation without a permanent audit record of who did it and when.
• Zero ToleranceNever edit, suppress, or delete a SAR, alert, or any statutory AML/KYC evidence. Regulated evidence is append-only.

High-Risk AI & Algorithmic Accountability

• Zero ToleranceNever ship an automated decision that controls access to financial services without the required human-oversight and explainability controls in place.
• Zero ToleranceNever treat an unknown or unmapped input (country, document type, risk band) as low or medium risk. Unknown means escalate.
• Zero ToleranceNever disable, bypass, or weaken a screening/monitoring or AI-decision control without authorisation and a permanent audit record.

AML Screening, Sanctions & PEP

• Zero ToleranceAlways block and escalate whenever a screening, sanctions, PEP, or KYC check is missing, errored, timed out, or returned a result you do not recognise. The safe default is never "approve".
• Zero ToleranceAlways treat an unknown or unmapped input (country, document type, industry, risk band) as high risk. Escalate it to a human. Never silently map it to low or medium.
• Zero ToleranceNever auto-approve a customer, transaction, or onboarding when a required check is incomplete, errored, or unverified.
• Zero ToleranceAlways record every screening decision so it cannot be changed. Save the inputs, the lists/provider and their versions, the result, who or what decided, and when. This lets you rebuild and defend the decision later (see Auditability & Evidence).
• Zero ToleranceNever disable, bypass, or weaken a screening/monitoring control, including the kill-switch, without authorisation and a permanent audit record.
• Zero ToleranceNever suppress, edit, or delete a Suspicious Activity Report, alert, or other statutory AML/KYC evidence. It is append-only.

Marketplace & Certification Readiness

• Zero ToleranceNever misrepresent our security or compliance posture to a marketplace, assessor, or customer. Claim only controls we actually have and can evidence (see Professional Ethics & Integrity).

Vendor & Third-Party Risk

• Zero ToleranceNever share customer or personal data with a third party without an appropriate agreement and a lawful basis for doing so.

Product Analytics & Telemetry Privacy

• Zero ToleranceNever send special-category data, full PII, secrets, or financial details into an analytics or telemetry tool (see Data Classification, Observability & Logging Hygiene).

International Data Transfers

• Zero ToleranceAlways store and process EU/regulated personal data in the correct region by default. Treat moving it (or making it accessible) outside that region as a decision that needs approval (see Azure & Cloud Platform).
• Zero ToleranceNever send EU personal data to a third country without an approved transfer mechanism and the required safeguards in place.

Customer Complaints Handling

• Zero ToleranceNever delete, hide, or alter a complaint record to make a problem disappear. Complaints are regulated evidence (see Professional Ethics).

Payment Card Security (PCI DSS)

• Zero ToleranceNever store, log, or transmit full card numbers (PAN), CVV/security codes, or full track data in our systems. CVV must never be stored at all (see Observability & Logging Hygiene).

Compliance Training & Competency

• Zero ToleranceNever falsify training records, or claim competency or completion you do not have (see Professional Ethics & Integrity).

.NET / C# Coding Standards

• Zero ToleranceNever ignore exceptions silently, catch Exception broadly just to be safe, or leak stack traces, SQL, or secrets to external callers (see Error Handling).
• Zero ToleranceNever log secrets, tokens, or full PII, and never put sensitive data into log strings with string interpolation (see Observability & Logging Hygiene).

HTML & Markup Standards

• Zero ToleranceNever inject untrusted HTML into the page (raw innerHTML, dangerouslySetInnerHTML, or MarkupString) without sanitising it. That is XSS (see Web & Frontend Security).

JavaScript Coding Standards

• Zero ToleranceNever put secrets or other users' data in client-side JavaScript. Everything sent to the browser can be read by the user (see Web & Frontend Security).

Blazor Coding Standards

• Zero ToleranceAlways enforce all authorization and validation on the server. In WebAssembly the C# runs in the browser and the user can see and edit it, so it is never a trust boundary (see Web & Frontend Security).
• Zero ToleranceNever send secrets, connection strings, or other users' data into a WebAssembly component. Anything in the WASM app is downloaded and readable by the user (see Secrets at Rest & in Transit).
• Zero ToleranceNever pass untrusted or user content to MarkupString or into DOM-writing JS interop without sanitising it. That is an XSS hole (see Web & Frontend Security).

React Coding Standards

• Zero ToleranceNever pass untrusted content to dangerouslySetInnerHTML without sanitising it, and never rely on the client for security or authorization. The server enforces it; a hidden button is not access control (see Web & Frontend Security).

SQL / T-SQL Coding Standards

• Zero ToleranceNever build SQL by concatenating input ("... WHERE x='" + v + "'"). That is SQL injection. Always pass values as Dapper parameters.
• Zero ToleranceAlways include the tenant predicate (WHERE TenantId = @t) on every read, update, and delete of tenant-owned data, taken from the validated context (see Multi-Tenancy).
• Zero ToleranceNever hard-delete regulated records (KYC, AML, audit, SARs). Soft-delete them with a role gate, tenant scope, and an audit entry (see Data Retention & Erasure).
• Zero ToleranceNever do a money- or balance-changing read-modify-write without concurrency control. Last-writer-wins loses money (see Concurrency).

HTTP Status Codes

• Zero ToleranceNever return 200 OK for a failed request. A 200 with an error in the body hides the failure from clients, proxies, caches, and monitoring (see REST API Conventions).
• Zero ToleranceNever use the status code to leak internal detail. Pair the right code with a safe Problem Details body — never a stack trace, SQL, or file path (see Error Handling).

REST API Conventions

• Zero ToleranceNever leak internal details (stack traces, SQL, secrets, file paths) in responses, or return another tenant's or user's data (see Multi-Tenancy, Error Handling).
• Zero ToleranceAlways authenticate and authorise every endpoint by default, derive identity and tenant on the server, and validate every request against the contract at the boundary (see Authentication & Authorization, Trust Boundaries).

GraphQL Conventions

• Zero ToleranceNever leak internal details (stack traces, SQL, secrets, file paths) in an error message or extension, or return another tenant's or user's data (see Multi-Tenancy, Error Handling).
• Zero ToleranceAlways limit query depth and cost. Reject queries that are too deeply nested or too expensive before running them, so one crafted query cannot exhaust the server (see Rate Limiting & Abuse Prevention).
• Zero ToleranceAlways authenticate the request and authorise every field that exposes protected data, deriving identity and tenant on the server. Do not rely on the client to omit fields it should not see (see Authentication & Authorization, Trust Boundaries).

gRPC & Protobuf Conventions

• Zero ToleranceNever return OK for a failed call. The status code is the result. An OK with an error packed into the response body hides the failure from clients, retries, and monitoring. Use the right error code.
• Zero ToleranceNever leak internal details (stack traces, SQL, secrets, file paths) in a status message or detail, or return another tenant's or user's data (see Multi-Tenancy, Error Handling).
• Zero ToleranceAlways set a deadline on every call and honour it on the server. A call with no deadline can hang forever and tie up resources. Propagate the incoming deadline to any downstream calls.
• Zero ToleranceAlways use TLS for every connection, and mTLS between internal services. Authenticate from metadata and authorise every RPC in an interceptor, deriving identity and tenant on the server (see Authentication & Authorization, Secrets at Rest & in Transit).
• Zero ToleranceNever reuse, renumber, or change the type of an existing field number. Field numbers are the wire contract. To drop a field, reserve its number and name so they are never used again.

Test Code Standards

• Zero ToleranceNever use real production PII or KYC data in tests or fixtures. Use synthetic or masked data only (see Test Data & Environments).

Shell & Scripting Standards (Bash / PowerShell)

• Zero ToleranceAlways read secrets from the vault or secure environment at runtime. Never hard-code them in scripts and never print or log them (see Secrets at Rest & in Transit).
• Zero ToleranceNever commit a secret in a script, or pipe a remote script straight into a shell (curl ... | bash) from a source you do not trust (see Dependency & Supply-Chain Security).