These notes explain the main modeling decisions so reviewers can challenge them. Each section ends with the question we expect the OCSF community to ask.
Banks need the same fraud alert to answer three different questions, so findings carry three independent layers:
| Layer | Attributes | Answers |
|---|---|---|
| What happened | fraud_type_id, fraud_mechanism_id, fraud_origin_id, is_authorized, involved_parties |
What scheme was this, and who did what to whom? |
| How it was done | finding_info.fraud_attacks |
Which fraud tactics and techniques were used? |
| How it is reported | loss_event_classification, regulatory_classifications |
Which operational risk category, and which regulator categories? |
Keeping them separate means one finding can feed fraud operations, operational risk loss data, and several regulators without anyone re-keying it.
In core OCSF, actor is whoever performed the action. In fraud that is often misleading: in an account takeover the authenticated actor is the victim’s account, and in an authorized payment scam the real customer pressed Send. The fraud profile therefore adds involved_parties, an array of parties each with a role_id (Account Holder, Victim, Initiator, Beneficiary, Suspected Perpetrator, Money Mule, Colluding Insider, Reporter) and is_employee. actor keeps its core meaning.
is_authorized records whether the legitimate account holder authorized the activity. It drives liability and reimbursement in many jurisdictions and is the cleanest split between scams and takeovers.
Question: should involved_parties move to core as a general mechanism for findings with victims?
fraud_mechanism_id values 1 to 3 (Unauthorized Issuance, Unauthorized Modification, Manipulation of Payer) match the three payment fraud types in the EBA guidelines on fraud reporting under PSD2. Value 4 (Account Holder Misrepresentation) covers first-party fraud. This lets EU statistics be produced directly; see mappings/eba_payment_fraud.json.
fraud_origin_id is External, Internal, or Collusion. Under the Basel definition, any loss involving at least one internal party is internal fraud, so Collusion maps to Basel Level 1 “Internal Fraud”. mappings/fraud_type_to_loss_event.json gives the default Level 2 category for each fraud type.
Insider telemetry comes from two new classes, Staff Operation Activity and Customer Record Access Activity, plus Account Maintenance Activity when staff make the change. The approval object records maker, checker, self-approval, and overrides. ldap_person.leave_time on the employee is used to flag staff who are leaving.
F3 reuses ATT&CK’s structure and identifiers where behaviors overlap and adds fraud-specific tactics (Positioning, Monetization). Rather than overload the core attacks attribute, whose definition names ATT&CK and ATLAS, the extension adds fraud_attacks, which reuses the core tactic, technique, and sub_technique objects and adds framework. Insider behaviors that neither F3 nor the insider threat knowledge base describe at banking-operations level are defined in mappings/internal_behaviors.json with INT- identifiers.
F3 identifiers are intentionally blank in this version. Copy them from the official F3 matrix; do not infer them.
Question: should F3 go into the core attacks attribute, as ATLAS did, instead of a separate attribute?
monetary_amount stores integer minor_units, an ISO 4217 currency_code, and minor_unit_exponent. Floats are never used for money. Transactions can also carry reporting_amount in the institution’s reporting currency with the fx_rate and fx_rate_time used, so losses can be aggregated across countries.
book_time and fraud_loss.loss_posted_time exist because regulators count losses in the period they are booked, which is often weeks after the event.
bin and last_four are the only number fragments allowed.modified_fields names what changed, never the old or new values.emp-pz-…, cust-…). Real deployments should pseudonymize employees in alerts until a case escalates, and keep alerts about an employee hidden from that employee and their management chain.regulatory_classifications must not record whether a suspicious activity report was filed, or any filing identifier. Many jurisdictions prohibit disclosing that a report exists.fraud_signals gathers detection inputs that core OCSF has no place for: device first seen on the account, emulator, remote access, active call, pasted input, SIM change, number port, line type, caller attestation level, synthetic voice score, behavioral biometric score, identity verification result, and watchlist matches. It is a profile so it can be applied to core Authentication and User Management as well as the new classes.
As an extension, identifiers are derived from the extension UID: category 30 becomes 98330, Transaction Activity becomes class 98330001, and its Initiate activity becomes type_uid 9833000101. In core these would become a single-digit category and four-digit class UIDs.