Security architecture

The data doesn’t
have to move.

Alerra is designed so institutions can contribute fraud intelligence without exposing their underlying customer database. The bank keeps its data, its policy and its decision. What crosses the boundary is a narrow, derived object the institution chose to publish.

Everything in this box stays inside the institution. Alerra has no route to it and exposes no function that could reach it.

Core bankingLedgers, balances, payments
Fraud engineThe bank’s own models and rules
Customer dataIdentity, profile, contact
Transaction dataFull history and detail

Runs under the institution’s control. It decides what may be derived, what may be published, and who may ask.

Policy enforcementInstitution-defined rules on every call
TokenisationIdentifiers become pseudonymous tokens
Signal extractionDerives the narrow fraud signal only
Access controlWhich counterparties may query what
Audit loggingEvery request, contribution and response
Evidence graphRelationships between pseudonymous entities
Network riskScored from evidence, with its reasons
Pattern detectionBehavioural similarity across institutions
ReputationEntity standing over time
Outcome learningConfirmed results become evidence
Live security demo

What leaves the bank?

A simulated payment, sitting inside the bank boundary. Press the button and watch exactly which fields cross it.

Customer
demo_customer_184
Destination
demo_account_7F29
Amount
$48,000
Device
demo_device_441

Synthetic record. None of these values is transmitted.

What moves, and what doesn’t.

Does not leave the bank

  • Customer name and identity
  • Raw transaction history
  • Credentials of any kind
  • Full customer profile
  • Raw internal datasets

Can be shared, subject to policy

  • Derived risk signal
  • Pseudonymous entity token
  • Pattern classification
  • Confidence
  • Observation count
  • Confirmed outcome

On identity matching. Hashing alone does not anonymise customer information, and Alerra does not claim that it does. Production identity matching can use controlled tokenisation, keyed cryptographic identifiers, privacy-preserving record linkage or institution-approved matching mechanisms depending on deployment requirements.

Security principles

Six commitments.

Data minimisation

Only the intelligence required for the fraud use case is exchanged. Not the record it was derived from, and not fields that do not serve the decision.

Institutional control

Each institution determines which capabilities and which signals its own gateway exposes, and to whom. The default is that nothing is exposed.

Zero generic database access

There is no query surface for browsing a bank’s records. The functions that would make it possible do not exist in the protocol.

Auditability

Every intelligence request, every contribution and every decision-support response can be logged, attributed and reviewed after the fact.

Explainability

A risk assessment returns the supporting evidence, not an unexplained score. An institution can interrogate every point it was given.

Decision sovereignty

Alerra provides intelligence and evidence. The financial institution makes the decision, applies its own policy, and owns the outcome.

The gateway surface

Narrow by construction.

The complete set of capabilities an institution’s gateway can expose. Short enough to print, which is the point.

check_destination_risk()Risk and evidence for a destination entity token.
check_scam_pattern()Match a behavioural pattern against network history.
check_behavioural_similarity()Similarity to confirmed case behaviour.
check_entity_reputation()Reputation for a pseudonymous entity token.
publish_fraud_signal()Contribute a derived signal to the network.
confirm_scam_outcome()Return a confirmed outcome as evidence.
Deliberately absent
get_customer() get_transactions() search_bank_database() list_accounts() export_customer_profile()
See the network live How it works