Compliance
What Straja processes, what it deliberately does not, and how each decision stays contestable and auditable. Written for whoever signs off on this integration.
What is processed
Exactly one object reaches the decision model: the 15-field signal vector below. Nothing else — no name, no account id, no free-text field the user has written anywhere on the page.
One deliberate exception, stated here rather than left to be discovered: idle_gaps_over_60s counts gaps of a minute or more in the product, but the public sandbox at /sandbox measures the same signal at 30 seconds, so a visitor can trigger it without sitting still for a full minute. The sandbox says so on screen, and it is the only surface where the threshold differs — every fixture-driven flow uses the real one.
| Signal | Plain-language meaning |
|---|---|
| account_age_days | How long the account has existed. |
| is_first_purchase | Whether this is the account's first transfer. |
| amount_eur | The transfer amount. |
| amount_vs_median | How this amount compares to the account's usual amount. |
| funding_method | How the transfer is being funded (card, bank transfer, Apple Pay). |
| minutes_to_outbound | Minutes between funding arriving and the outbound transfer. |
| destination_first_seen_days | How long this destination has been on record, if at all. |
| destination_type | The category of destination — a fresh address, a known exchange, a contract, or self-custody. |
| declined_attempts | How many prior attempts on this transfer were declined. |
| address_entry_method | Whether the destination address was pasted, typed, or scanned. |
| idle_gaps_over_60s | How many times the session went idle for over a minute. |
| tab_switches | How many times the page lost and regained visibility. |
| deposit_escalation | The sequence of amounts across recent deposits, if escalating. |
| kyc_retries | How many times identity verification was retried. |
| merchant_verified | Whether the receiving party is a registered, vetted merchant — null when there is no merchant involved (a direct wallet or exchange transfer). |
What is deliberately not captured
Behavioural monitoring reads as invasive until the boundaries are named plainly. Straja never captures:
- Keystroke content — what was typed, not just that typing happened
- Screen contents or page text
- Message or chat content, on this platform or any other
- Contact lists or any social graph
- Audio, video, or camera/microphone access of any kind
Governance
Lawful basis
Processing is carried out under legitimate interest in preventing fraud — a recognised basis under GDPR Recital 47 for exactly this purpose. It also supports the partner's own AML obligations: behavioural signals that indicate coercion or a real-time scam in progress are directly relevant to Know Your Customer and suspicious-activity monitoring duties, not a separate initiative bolted on alongside them.
Data minimisation
The decision model receives only the signal vector — never an account id, name, email, or IP address. Identity fields are held by the calling partner and never leave their own systems; Straja's model has no way to re-identify who a given signal vector belongs to, because it is never given the means to.
Automated decision-making
Under GDPR Article 22, this system is designed to stay on the permitted side of automated decision-making: it never blocks a transfer outright. At most it delays one, with a plain-language explanation of why and a concrete way to verify the concern. The user can always proceed. Every decision is logged with its full reasoning and is reviewable by a person — nothing here is a final, unappealable automated refusal.
Audit trail and retention
Every decision — the signal vector received, the tier assigned, the model's reasoning, and (for a held transfer) the follow-up conversation and the user's eventual choice — is written to an append-only decision record the moment it happens. Records are retained for as long as the partner's own transaction-monitoring retention policy requires, since that is the obligation this system exists to support; this demo keeps them indefinitely in a local JSONL store, with no automatic purge.
Markets and limitations
This is a behavioural layer, not a licensed compliance product — it supports a partner's existing AML/KYC program rather than replacing any part of it. Before deployment in a new market, a partner's own legal team should confirm the lawful basis holds locally, that the retention period matches local requirements, and that the pattern-screen language has been reviewed for that jurisdiction's consumer protection rules around financial services communication.