@1aboveio/skills 0.0.0-stage → 1.0.0

package/skills/risk-compliance/fraud-analysis/references/feature-engineering.md

@@ -0,0 +1,158 @@
+# Shared feature engineering
+
+Read this in Step 4 after pre-flight passes, the analysis profile is selected,
+and its packs are loaded.
+This file defines invariants. Archetype, mechanism, and context packs supply the
+actual feature families and operational constraints.
+
+The goal is a small set of interpretable, decision-time-valid inputs that can
+become rules. Build thresholds, lists, rates, and graph artifacts on train only.
+
+## 1. Declare grain and decision point
+
+Name what one scored row represents and when the rule fires. Examples include a
+login, card authorization, collection receipt, beneficiary creation, transfer
+instruction, payout request, or investigation case.
+
+A feature is usable only if its value existed at that decision point in the live
+workflow. Correlation with the eventual label is insufficient.
+
+For linked journeys, a rule may use prior event types, but never a future event:
+
+```text
+login → profile change → beneficiary creation → collection → transfer → payout
+```
+
+The position of the scored event determines what is known.
+
+## 2. Classify every field
+
+For each source and engineered field, record:
+
+1. Business meaning
+2. Event grain
+3. When it becomes known
+4. Whether it is the label or a synonym
+5. Whether it uses current, prior, or future events
+6. Whether the identity link is strong enough for the claim
+
+Place it in one list:
+
+- **Allowed now** — decision-time-valid and variable
+- **Excluded: zero variance** — baseline context, not a feature
+- **Excluded: timing** — real information available too late
+- **Excluded: leakage** — target, synonym, or post-outcome artifact
+- **Context only** — useful description but not operable in the target system
+
+Do not silently drop exclusions. Include them in analysis notes and summarize
+material exclusions in the report appendix.
+
+## 3. Shared feature families
+
+Use only families supported by the selected packs and source data:
+
+- Current-event attributes: amount, currency, channel, product, state available
+  at decision time
+- Entity history: customer, account, instrument, beneficiary, device, session,
+  IP, email, phone, merchant, or counterparty
+- Velocity: prior counts, amounts, distinct entities, and elapsed time over
+  operational windows
+- Novelty and deviation: new entity, behavior unlike the entity's prior history,
+  amount relative to prior behavior
+- Sequences: explicit prior-event patterns across the money or access journey
+- Networks: fan-in, fan-out, shared identifiers, clusters, and risky-neighbor
+  evidence from a point-in-time graph
+- Train-fit lists: entities or segments with minimum support and elevated rate
+
+## 4. Point-in-time history
+
+- Sort events deterministically by time within each identity key.
+- Use timestamps strictly before the current event. Define tie behavior.
+- Holdout rows may use train-era history that predates the row.
+- Never use the current row's outcome in its own features.
+- Graph nodes, edges, labels, and aggregates must be snapshots as of the event.
+- Outcome labels become historical evidence only after they would have been known
+  operationally, not merely after the underlying transaction occurred.
+
+Use windows operations can implement, such as 10m, 1h, 24h, or 7d. Avoid exact
+sequences and fine windows selected only because they maximize train fit.
+
+## 5. Identity-link quality
+
+Document whether keys identify a person, account, instrument, device, session,
+or merely a shared attribute. Masked identifiers, IPs, addresses, and devices may
+collide or be shared.
+
+- Do not turn a weak key into a claimed unique customer or account.
+- Do not infer knowing participation from shared infrastructure alone.
+- Distinguish deterministic links from probabilistic links.
+- Keep network-derived high-risk lists monitor-only when link quality or actor
+  attribution is weak.
+
+## 6. Labels and outcome maturity
+
+Fraud, scam, recalls, returns, disputes, reimbursements, investigations, and
+account restrictions often mature after the event.
+
+- Define when an outcome becomes observable.
+- Exclude immature recent events or treat them as unlabeled, not clean negatives.
+- Record whether the label comes from an existing outcome column or a
+  user-defined condition.
+- For an existing row-level outcome column, mapped positive values may use all
+  other mature values as negative unless an explicit pending/unknown/unlabeled
+  value exists. State this assumption and preserve those explicit states as
+  unlabeled.
+- For a user-defined positive condition, require a separate user-defined
+  negative condition. Rows outside the positive condition are not automatically
+  negative.
+- Verify positive and negative conditions are disjoint. Exclude rows matching
+  neither or both from supervised metrics and report their count.
+- Fit label-rate lists on mature train outcomes only.
+- Do not use an operational action as both label and feature.
+- Do not blend separate archetypes into a single positive label.
+
+## 7. Train-fit thresholds and lists
+
+- Propose thresholds from business meaning or train distributions.
+- Require minimum support for entity, graph, or segment lists.
+- Freeze conditions and memberships before holdout scoring.
+- Apply frozen artifacts to holdout without reranking on holdout outcomes.
+- Small-N spikes remain monitoring candidates.
+
+## 8. Rule-ready conditions
+
+Every shortlisted candidate must specify:
+
+```text
+event grain + decision point + fields + operator + threshold/list + units + window
+```
+
+Prefer:
+
+- `amount >= <currency threshold>` over “high amount”
+- `prior_attempts_1h >= 3` over “high velocity”
+- `beneficiary_age_minutes <= 30` over “new beneficiary”
+- `entity in train_fit_watchlist_v1` over a holdout-ranked list
+
+## 9. Universal do-not list
+
+- Do not use zero-variance fields as rule conditions.
+- Do not use future events, current outcomes, or investigation results.
+- Do not treat technical authentication as proof of customer consent.
+- Do not infer victim, perpetrator, mule, or facilitator role from behavior alone.
+- Do not fit thresholds, rates, graph lists, or watchlists on holdout.
+- Do not present proxy labels as confirmed fraud or loss avoided.
+- Do not invent missing fields, identity links, currencies, or event semantics.
+
+## 10. Ready-for-selection checklist
+
+- [ ] Analysis profile loaded
+- [ ] Event grain and decision point stated
+- [ ] Outcome maturity defined
+- [ ] Label provenance and positive/negative/unlabeled definitions recorded
+- [ ] Positive and negative conditions are disjoint
+- [ ] Fields classified into allowed/excluded/context-only lists
+- [ ] History and graph features are point-in-time
+- [ ] Identity-link strength documented
+- [ ] Thresholds and lists fit on train only
+- [ ] Candidates expressed as operable conditions

package/skills/risk-compliance/fraud-analysis/references/mechanisms/account-takeover.md

@@ -0,0 +1,36 @@
+# Mechanism: account takeover
+
+An external actor gains control of a genuine customer's account or authenticated
+session. This normally composes with `third-party-fraud`; if consent or knowing
+participation is unresolved, keep the archetype `unclassified`.
+
+## Key distinction
+
+Technical authentication is not customer consent. A criminal may pass password,
+MFA, device, session, or transaction authentication using compromised access.
+
+## Feature families
+
+- New device, browser, IP, ASN, geography, or session
+- Password, MFA, phone, email, recovery, or trusted-device changes
+- Failed-login bursts, credential-stuffing indicators, and impossible travel
+- Session age, authentication strength, and deviation from trusted behavior
+- New beneficiary after access changes; login-to-transfer/payout velocity
+- Shared devices, IPs, recovery identifiers, or beneficiaries across accounts
+
+Only use events before the rule's decision point. Do not use later compromise
+confirmation, customer contact, session revocation, or investigation findings.
+
+## Actions
+
+Depending on context: terminate session, require reauthentication through an
+independent channel, reset credentials, remove trusted devices, cool off new
+beneficiaries, hold/review money movement, and restrict the account where policy
+permits.
+
+## Review overlay
+
+- Authentication success is not described as genuine-customer authorization.
+- Recovery and profile-change timestamps precede the scored event.
+- Device/IP novelty uses only prior customer history.
+- Shared infrastructure such as carrier NAT is not treated as identity proof.

package/skills/risk-compliance/fraud-analysis/references/report-rationale.md

@@ -0,0 +1,45 @@
+# Report rationale (agent only)
+
+This explains the business report contract. Do not copy it into deliverables.
+
+## Why composition matters
+
+Archetype, mechanism, and context answer different questions:
+
+- Archetype identifies the genuine customer's relationship to fraud.
+- Mechanism explains compromise, deception, or deliberate abuse.
+- Context identifies the operational control point and business denominator.
+
+Keeping them independent prevents category errors such as treating account
+takeover as a peer of first-party fraud, treating every authenticated transfer as
+customer-authorized, or applying 3DS and authorization-success metrics to payout
+and collection controls.
+
+## Report choices
+
+| Choice | Reason |
+|---|---|
+| Profile before label | The same status can represent different actors and outcomes across archetypes |
+| Explicit negative class | Precision, recall, and lift are undefined or misleading when “not positive” silently mixes genuine negatives with unknown outcomes |
+| Consent separate from authentication | Compromised credentials can pass technical checks |
+| Reader order differs from workflow | Operators need decisions before methodology |
+| Standalone strategy impact | Portfolio friction and exposure determine whether rules should ship |
+| Count/rate and amount/share | Both operational volume and value matter |
+| Context-specific impact | Authorization, completion, delay, review, and exposure use different denominators |
+| Proxy and maturity disclosure | Delayed outcomes and operational actions are not confirmed fraud by default |
+| Point-in-time graphs | Future counterparties and investigations otherwise leak into earlier events |
+| No review process in report | Review metadata is not business content |
+
+## Domain examples
+
+- `third-party-fraud + card-payment` loads card/BIN/3DS and authorization-impact
+  guidance.
+- `third-party-fraud + account-takeover + bank-transfer` loads access/session,
+  beneficiary, transfer, and consent-versus-authentication guidance.
+- `first-party-fraud + payment-collection + payout` loads money-flow, graph,
+  settlement, hold, workload, delay, and exposure guidance.
+- `authorized-payment-scam + bank-transfer + app-scam` loads deception,
+  beneficiary, warnings, completion, reimbursement, and customer-impact guidance.
+
+If archetype attribution is unresolved, the report should say so and limit claims
+and actions accordingly rather than manufacturing certainty.

package/skills/risk-compliance/fraud-analysis/references/report-template.md

@@ -0,0 +1,190 @@
+# Business report contract
+
+Read this in Step 8 with the selected profile packs and
+[terminology.md](terminology.md). This file owns common reader order and metric
+presentation. Profile packs own domain-specific actions, sections, denominators,
+and impact measures.
+
+## Required chapter order
+
+1. 执行摘要
+2. 抽样、分析画像与标签定义
+3. 规则发现
+4. 策略整体影响
+5. 特征
+6. 附录
+
+Do not title chapters as analysis steps. Keep review details out of the report.
+
+## 1. 执行摘要
+
+Use no more than five top-level findings:
+
+1. Analysis profile, sample span, and positive-label baseline
+2. Adopted rule classes and domain-appropriate actions
+3. Adopted strategy package impact
+4. Material attribution or validation limitation, only when decision-critical
+
+For strategy impact, report triggered count/rate and amount/share, followed by
+precision and recall. Add the selected contexts' main customer, operations,
+conversion, delay, exposure, or loss measure.
+
+Nested numbered lists use three-space indentation and `1.`, `2.`, `3.` markers.
+Do not use Markdown bold markers in the report body.
+
+## 2. 抽样、分析画像与标签定义
+
+### 2.1 样本范围
+
+Data source, event grains, time span, currencies, and portfolio constants.
+
+### 2.2 分析画像与归因
+
+Use a compact table:
+
+| Field | Value |
+|---|---|
+| Archetype | Third-party fraud / First-party fraud / Authorized payment scam / Unclassified |
+| Customer role | Victim / Perpetrator / Knowing participant / Facilitator / Unknown |
+| Customer consent | Present / Absent / Disputed / Unknown |
+| Technical authentication | Passed / Failed / Not applicable / Unknown |
+| Mechanism | e.g. Account takeover |
+| Context | Card payment / Collection / Bank transfer / Payout |
+| Attribution confidence | Confirmed / Probable / Proxy / Unknown |
+| Decision point | Exact operational point |
+
+Explain unresolved attribution. Do not imply consent from authentication.
+
+### 2.3 标签定义
+
+State label provenance (`file-column` or `user-defined`), confirmed versus proxy,
+and maturity window. Define and count all three populations:
+
+| Population | Required content |
+|---|---|
+| Positive | Exact values/conditions and count |
+| Negative | Exact values/conditions and count |
+| Unlabeled | Pending, immature, unknown, overlapping, or out-of-scope conditions and count |
+
+Report the positive base rate among labeled rows and its denominator. If an
+existing outcome column supplies the positive label, disclose the assumption
+that its other mature, non-explicitly-unlabeled values are negative. If the user
+defined the positive condition, show the separately supplied negative condition.
+Separate labels for separate archetypes.
+
+### 2.4 时间切分
+
+State cut and train/holdout sizes, or state that metrics are in-sample and
+unvalidated. Name the decision point again in one line.
+
+## 3. 规则发现
+
+### 3.1 规则清单与验证集指标
+
+Suggested columns:
+
+```text
+规则类 | 事件与决策时点 | 条件 | 触发率 | 精准率 | 召回率 | lift | 建议动作
+```
+
+- Group conditions into a few operational rule classes.
+- State explicit windows, units, currency, and frozen-list versions.
+- Use actions supplied by selected context packs.
+- List rules once. Multi-rule unions belong to strategy packages in chapter 4.
+
+### 3.2 稳定性与归因
+
+Report temporal instability, small support, weak identity links, proxy outcomes,
+and actor-attribution uncertainty that change action severity.
+
+### 3.3 可落地运营建议
+
+Describe the default package and optional higher-coverage package. Identify
+policy, legal, rail, and operational dependencies for severe interventions.
+
+## 4. 策略整体影响
+
+This is always a standalone chapter.
+
+### 4.1 触发覆盖与标签效果
+
+For every package/action row, report in this order:
+
+1. Triggered count and rate
+2. Triggered amount and amount share, with currency
+3. Precision
+4. Recall
+
+Suggested columns:
+
+```text
+方案 | 动作 | 触发笔数 | 触发率 | 金额 | 金额占比 | 精准率 | 召回率
+```
+
+For mixed currencies without FX conversion, do not sum unlike currencies; show
+separate currency rows or explicitly label any supplied reporting currency.
+
+### 4.2 Domain impact
+
+Use only measures required by selected context packs:
+
+| Context | Typical measures |
+|---|---|
+| Card payment | 3DS/block coverage, authorization success, approval count |
+| Collection | availability delay, return/loss exposure, accepted value |
+| Bank transfer | completion/abandonment, warning/review load, delay, reimbursement exposure |
+| Payout | completion/release, hold duration, review load, exposure |
+
+Separate observed measures from scenario estimates. State every scenario
+assumption and denominator. Do not claim loss prevented from proxy labels.
+
+### 4.3 方案比较（optional）
+
+Compare one recommended and one higher-coverage package under identical
+assumptions. Keep stricter non-default actions visibly separate.
+
+## 5. 特征
+
+### 5.1 入选短名单
+### 5.2 候选特征集
+### 5.3 训练拟合的观察名单或图谱特征（when applicable）
+
+Keep this shorter than rule findings. Name point-in-time construction and weak
+links where material.
+
+## 6. 附录
+
+### A. 决策时点与字段排除
+### B. 标签成熟度、时间切分与训练指标
+### C. 仅描述性信号与未入选候选
+### D. 假设、限制与政策依赖
+
+## Skeleton
+
+```markdown
+# 风险规则分析 — <scope>
+
+数据源：`…`
+分析画像：<archetype> / <mechanism> / <contexts>
+决策时点：<event and point>
+
+## 1. 执行摘要
+## 2. 抽样、分析画像与标签定义
+### 2.1 样本范围
+### 2.2 分析画像与归因
+### 2.3 标签定义
+### 2.4 时间切分
+## 3. 规则发现
+### 3.1 规则清单与验证集指标
+### 3.2 稳定性与归因
+### 3.3 可落地运营建议
+## 4. 策略整体影响
+### 4.1 触发覆盖与标签效果
+### 4.2 <selected context impact>
+### 4.3 方案比较
+## 5. 特征
+### 5.1 入选短名单
+### 5.2 候选特征集
+### 5.3 观察名单或图谱特征
+## 6. 附录
+```

package/skills/risk-compliance/fraud-analysis/references/review-checklist.md

@@ -0,0 +1,175 @@
+# Independent review checklist
+
+Use after the report is written. Review the common contract below plus every
+selected archetype, mechanism, and context pack. Do not re-mine features unless
+a fatal issue requires a user-approved restart.
+
+## Inputs
+
+- Draft report and source paths
+- Analysis profile, event grain, and decision point
+- Label definition, maturity window, and attribution confidence
+- Time cut and train/holdout sizes, or explicit in-sample status
+- Allowed and excluded fields
+- Rule definitions and metrics with evaluation window
+- Strategy actions, impact measures, denominators, and assumptions
+- Selected profile pack paths
+
+## Verdicts and severity
+
+| Verdict | Meaning |
+|---|---|
+| PASS | Common and profile checks clear |
+| PASS_WITH_FLAGS | Valid with residual monitoring or judgment issues |
+| NEEDS_CHANGES | Mechanical or substantive issues require repair |
+| BLOCKED | Label, attribution, timing, or data foundation is unusable |
+
+| Severity | Response |
+|---|---|
+| mechanical | Auto-fix and recheck |
+| judgment | Surface; do not silently change attribution or action |
+| fatal | Stop and ask the user |
+
+## Common method checks
+
+### Pre-flight
+
+- [ ] Pre-flight status passed before supervised analysis began
+- [ ] Input readability, row grain, time field, and label provenance were checked
+- [ ] File-column positives map remaining mature rows to negative only after
+  preserving explicit missing/pending/unknown/unlabeled states
+- [ ] User-defined positives received an explicit user-defined negative condition
+  during pre-flight; `NOT positive` was not silently assumed
+- [ ] Both/neither/immature rows are unlabeled, or their absence is demonstrated
+- [ ] Descriptive-only analysis is clearly separated from supervised metrics when
+  pre-flight could not establish both classes
+
+### Analysis profile and attribution
+
+- [ ] Exactly one primary archetype, or separate analyses for multiple archetypes
+- [ ] Customer role, consent, technical authentication, mechanism, context,
+  attribution confidence, event grain, and decision point are stated
+- [ ] Technical authentication is not used as proof of genuine-customer consent
+- [ ] First-party means knowing participation; authorized-payment scam means a
+  deceived victim; third-party means absent genuine-customer consent
+- [ ] APP terminology is limited to authorized push payments
+- [ ] Unresolved victim/participant attribution remains unclassified
+
+### Label and maturity
+
+- [ ] Label provenance is stated as file-column or user-defined
+- [ ] Exact positive, negative, and unlabeled definitions and counts are stated
+- [ ] Existing outcome-column labels disclose the assumption used to map other
+  mature values to negative and preserve explicit pending/unknown states
+- [ ] User-defined positive labels have a separately user-defined negative class;
+  all other rows are not automatically treated as negative
+- [ ] Positive and negative conditions are disjoint; neither/both rows are unlabeled
+- [ ] Confirmed versus proxy status is honest
+- [ ] Positive base rate is factual and uses labeled rows as denominator
+- [ ] Outcome maturity window is defined; immature rows are not clean negatives
+- [ ] Separate archetypes are not blended into one target
+- [ ] Label, synonyms, actions, and later investigation outcomes are excluded
+
+### Temporal validation
+
+- [ ] Earlier train and later holdout cut is stated, or metrics are unvalidated
+- [ ] No random split is presented as temporal validation
+- [ ] Headline metrics come from the claimed window
+- [ ] Thresholds, rate lists, graph lists, and watchlists are fit on train only
+- [ ] Holdout rows may use only history known before each row
+
+### Decision-time validity
+
+- [ ] Every rule field exists at the stated decision point
+- [ ] Current response, settlement, return, recall, dispute, reimbursement,
+  restriction, and investigation fields do not leak backward
+- [ ] History uses prior events and defines timestamp ties
+- [ ] Graph features are point-in-time snapshots
+- [ ] Zero-variance, timing, leakage, and context-only exclusions are listed
+- [ ] Weak entity links are not presented as unique identities
+
+### Metrics and actions
+
+- [ ] Rule metrics use occurrence → precision → recall
+- [ ] Count metrics remain present when value metrics are added
+- [ ] Small-N, unstable, or attribution-uncertain segments are monitored or dropped
+- [ ] Actions come from selected contexts and match precision/evidence severity
+- [ ] Holds, freezes, rejects, restrictions, and reporting state policy/legal
+  dependencies where applicable
+
+## Common report checks
+
+- [ ] Reader order is executive summary → sample/profile/label → rules →
+  strategy impact → features → appendix
+- [ ] Analysis profile and attribution table appears near the start
+- [ ] Strategy impact is a standalone chapter
+- [ ] Every package/action has triggered count/rate and amount/share with currency,
+  followed by precision and recall
+- [ ] Mixed currencies are not summed without documented FX conversion
+- [ ] Domain impact measures and denominators come from selected context packs
+- [ ] Observed results are distinct from scenario estimates
+- [ ] Proxy labels are not translated into measured loss prevented
+- [ ] Executive summary has no more than five top-level findings
+- [ ] No Markdown bold markers or review-process details in the report
+- [ ] Fixed terminology is consistent with `terminology.md`
+- [ ] Banned strings in `terminology.md` have no unexplained hits
+
+## Required profile overlays
+
+Read and check each selected pack. At minimum:
+
+### Third-party fraud
+
+- Unauthorized outcome is supported; not every decline/dispute is fraud.
+- Behavioral deviation uses the genuine customer's prior history.
+
+### First-party fraud
+
+- Evidence supports knowing participation, not merely unusual behavior.
+- Mule/facilitator attribution is not inferred from money flow alone.
+- Restrictions and reporting identify policy/legal dependencies.
+
+### Authorized payment scam
+
+- Consent and deception are both supported.
+- Civil dispute and knowing participation are not mislabeled as scams.
+- Warnings/holds include customer and vulnerability impact.
+
+### Account takeover
+
+- Authentication success is separate from customer consent.
+- Profile/recovery changes and device novelty are point-in-time.
+- Shared IP/device infrastructure is not identity proof.
+
+### Card payment
+
+- Current CVV, AVS, authorization response, and 3DS result respect timing.
+- BIN lists are train-fit; issuer name is live-operable if used.
+- 3DS failures are outside subsequent authorization denominator.
+
+### Collection, transfer, and payout
+
+- Settlement, reversibility, completion, return, and recall timing are correct.
+- Sequence and graph features are point-in-time.
+- Completion, abandonment, delay, workload, and exposure denominators are stated.
+
+## Finding format
+
+```text
+- severity: mechanical | judgment | fatal
+- axis: profile | label | time | decision-time | metrics | actions | report | claims
+- item: <short title>
+- evidence: <specific report location or missing artifact>
+- required_fix: <concrete repair or ask user>
+```
+
+End with:
+
+```text
+VERDICT: PASS | PASS_WITH_FLAGS | NEEDS_CHANGES | BLOCKED
+REVIEWER_MODEL: <id or fallback note>
+AXES: method=…; profile=…; presentation=…
+```
+
+After mechanical fixes, recheck all mechanical items and ensure the repair did
+not alter attribution, introduce leakage, or change action severity silently.

package/skills/risk-compliance/fraud-analysis/references/taxonomy.md

@@ -0,0 +1,79 @@
+# Fraud analysis taxonomy
+
+Read this before defining a label. The dimensions are independent: an archetype
+describes the genuine customer's relationship to the fraud, a mechanism explains
+how it happened, and a context identifies where a control operates.
+
+## Archetype router
+
+| Customer consent | Customer participation | Deceived about recipient or purpose | Archetype |
+|---|---|---|---|
+| absent | no | no / unknown | `third-party-fraud` |
+| present | knowing | no | `first-party-fraud` |
+| present | no | yes | `authorized-payment-scam` |
+| disputed / unknown | unknown | unknown | `unclassified` |
+
+Ask:
+
+1. Did the genuine customer consent to this transaction?
+2. Did the customer knowingly participate in the abuse?
+3. Was the customer deceived about the recipient or payment purpose?
+
+Authorization language is overloaded. Record both:
+
+- **Customer consent** — whether the genuine customer intended the transaction.
+- **Technical authentication** — whether credentials, device, session, MFA, or
+  payment authentication passed.
+
+A technically authenticated transaction can still be unauthorized by the
+genuine customer after account takeover.
+
+## Archetypes
+
+### Third-party fraud
+
+An external actor uses another person's account, credentials, instrument, or
+identity without genuine-customer consent. Examples: stolen card, stolen token,
+credential theft, account takeover.
+
+### First-party fraud
+
+The genuine customer or account holder is the perpetrator or a knowing
+participant and misrepresents, manipulates, or deliberately misuses their own
+account for gain. Examples: deliberate collection abuse, false non-receipt or
+refund claims, knowing mule activity, deliberate payout abuse.
+
+Do not call this `first-party scam`: scam usually implies a deceived victim.
+
+### Authorized payment scam
+
+The genuine customer authorizes a payment but is deceived about its recipient or
+purpose. The customer is the victim, not a knowing participant.
+
+`APP scam` is a subtype for a victim-deceived push payment, normally in a bank
+transfer context. Do not apply APP terminology to all authorized payment scams.
+
+### Unclassified
+
+Use when consent, deception, or knowing participation cannot yet be established.
+Analyze observable risk signals, but do not claim archetype-specific loss or use
+the unresolved class as confirmed ground truth.
+
+## Mechanisms and contexts
+
+Mechanisms may include `account-takeover`, stolen payment credential, social
+engineering, synthetic identity, or deliberate account misuse. Add a mechanism
+pack only when its data and controls require specialized guidance.
+
+Supported contexts are `card-payment`, `payment-collection`, `bank-transfer`,
+and `payout`. Select all relevant contexts for linked money-flow analysis, but
+name the event grain and decision point for every rule.
+
+## Mixed cases
+
+- Separate confirmed archetypes into separate targets and metrics.
+- A mule may be a knowing participant (first-party fraud), a coerced or deceived
+  victim (authorized payment scam or unclassified), or an account-takeover victim
+  (third-party fraud). Do not infer the role from rapid movement alone.
+- A customer claim is evidence, not automatic proof of consent or attribution.
+- Civil disputes and service dissatisfaction are not automatically fraud.