Security Architecture

Authentication, authorisation, service-to-service security, audit trail, and regulatory compliance boundaries.

13.1 Authentication and Authorisation
1. Role-Based Access Control
13.2 Audit Trail
13.3 Regulatory Compliance Boundaries
1. The Compliance Boundary Is the API
13.4 Data Sovereignty Considerations

13.1 Authentication and Authorisation

Layer	Mechanism
Operator login	OIDC (identity provider integration) → JWT
API authorisation	JWT claims → Spring Security RBAC
GraphQL field-level security	Spring Security + GraphQL field visibility by role
Service-to-service	mTLS via AWS App Mesh (Envoy)
Temporal	mTLS between client, worker, and server; TLS at rest
Aurora	IAM database authentication + TLS in transit
S3	Pre-signed URLs (time-limited, user-scoped) + S3 bucket policy
Secrets	AWS Secrets Manager → injected into EKS pods via External Secrets Operator

Role-Based Access Control

The operator workspace enforces role-based panel visibility at both the GraphQL resolver layer and the React component layer. Role filtering at the resolver layer is the authoritative boundary — React-side filtering is a UX convenience only.

Role	Access
`BANKER` / `RM`	Case intake, status view (own cases), AI Assistant
`DOCUMENT_REVIEW_ANALYST`	Document Review Panel, document viewing
`BSA_OFFICER`	BSA/AML (Bank Secrecy Act / Anti-Money Laundering) Review Panel, attestation
`OPERATIONS_SUPERVISOR`	Order Approval Panel (Enterprise only)
`PRODUCT_OPERATIONS`	Product Operations Panel, identifier workflow
`OPERATIONS_TEAM`	Credential Delivery Panel
`ERROR_RECOVERY_HANDLER`	Error Recovery Panel
`MANAGER`	Executive Dashboard, full queue view, metrics

13.2 Audit Trail

Every case action — human or system — writes an immutable row to audit_events:

-- Required fields (7 mandatory for BSA/AML audit records):
--   case_id, event_type, actor_id, actor_type,
--   actor_name, event_at, payload
-- Optional: ip_address, session_id

-- The application database role has no UPDATE or DELETE on this table.
-- A separate compliance role has SELECT only.

Append-only enforcement: The application database role (anchita_app) is granted INSERT and SELECT on audit_events, but not UPDATE or DELETE. The table uses fillfactor = 90 to optimise for append-heavy workloads. A row written to audit_events cannot be modified or deleted by any application code path.

Event types captured:

Actor Type	Examples
`USER`	Case created, document uploaded, approval submitted, BSA attested, credential confirmed
`SYSTEM`	Workflow phase transition, Core Banking lookup, product provisioned, timer fired
`AI_AGENT`	Document pre-assessment written, AML field pre-filled, AI suggestion accepted/rejected

Retention: 7-year lifecycle policy for AML records (Bank Secrecy Act regulatory requirement). The S3 document lifecycle policy enforces the same 7-year retention for uploaded documents.

13.3 Regulatory Compliance Boundaries

Regulation	Constraint	Platform Implementation
BSA 31 USC 5318(g)	BSA Officer attestation cannot be automated	`submitBSAAttestation` signal requires human actor with `BSA_OFFICER` role; `ai_auto_approved` flag blocked for this task type in workflow code
FinCEN CDD Rule 31 CFR 1010.230	Beneficial ownership must be verified	CDD data captured in intake form; stored in `companies.related_entities` JSONB; displayed in BSA Review Panel
Reg E	User consent for electronic fund transfer enrollment	Consent captured and stored in `audit_events` before EFT provisioning activity; consent record references the operator and timestamp
OCC Guidance on Automated Decisioning	Change management for automated decisioning	AI suggestions logged with confidence score; human override always available; override reason captured in audit trail

The Compliance Boundary Is the API

Anchita treats compliance gates as engineering constraints, not configuration flags. The BSA attestation signal type definition enforces the constraint:

// The signal handler validates actor role — not a feature flag
@SignalMethod
public void submitBSAAttestation(AttestationRecord record) {
    // AttestationRecord.attestingOfficerId is validated against
    // the BSA_OFFICER role in the user-service before the signal
    // is accepted. No bypass path exists.
    this.attestation = record;
    this.bsaAttestationReceived = true;
}

There is no admin override. There is no force_approve parameter. The compliance boundary is the type.

13.4 Data Sovereignty Considerations

For a regulated banking environment, data sovereignty is a key factor in LLM provider selection. This is why AWS Bedrock is the preferred LLM provider for the AI Assistant and agents — all LLM inference requests stay within the AWS environment, with no data leaving the bank’s cloud boundary.

This is an open decision (not yet finalised). See Open Questions for the full decision matrix.