制定数据验证规则

Data element: Transaction Amount

Definition

• Purpose: Monetary value associated with a financial transaction.
• Data type: Fixed-point decimal or integer in minor units (recommended).
• Currency dependency: Precision and allowed decimal places depend on the transaction currency per ISO 4217 minor unit (exponent).
• Sign convention: Configurable by transaction_type (e.g., debit, credit, refund) and account/ledger rules.

Validation rules

Syntactic and type integrity

• R1. Not-null
  • Rule: amount must be present for any posted or authorized monetary transaction.
  • Severity: Reject.
• R2. Numeric and finite
  • Rule: amount must be a numeric value; NaN, Infinity, and string formats are not allowed in stored data fields.
  • Severity: Reject.
• R3. Fixed-point representation
  • Rule: amount must be stored using fixed-point decimal with defined precision/scale or as integer in minor units (e.g., cents).
  • Severity: Reject.

Currency-scale and precision

• R4. Decimal places match currency minor unit
  • Rule: decimal scale must equal the currency’s minor unit (ISO 4217). For example, USD=2, JPY=0, KWD=3.
  • Severity: Reject.
• R5. Rounding mode
  • Rule: when calculations produce more precision than allowed, round to the currency minor unit using a defined rounding mode (e.g., round half up or bankers rounding). The rounding mode must be consistent across all services and documented.
  • Severity: Reject if not conformant; Flag if internal intermediate breach before normalization.

Value range and sign

• R6. Non-zero (default)
  • Rule: amount must be > 0 for standard purchase, transfer-out, or deposit transactions.
  • Exception: amount may be < 0 for refunds/chargebacks or = 0 for authorization reversals; exceptions must be explicitly whitelisted by transaction_type.
  • Severity: Reject if outside allowed ranges for the given transaction_type.
• R7. Sign aligned with transaction_type
  • Rule: sign must match the transaction_type-to-sign mapping (e.g., debit=positive, credit=negative) defined in policy.
  • Severity: Reject.
• R8. Maximum per transaction
  • Rule: amount must not exceed Policy.MaxPerTransaction[currency] for the customer/segment/risk tier.
  • Severity: Reject.
• R9. Minimum per transaction
  • Rule: amount must be >= Policy.MinPerTransaction[currency], respecting currency minor units.
  • Severity: Reject.

Contextual and business consistency

• R10. Currency consistency
  • Rule: amount’s precision and rounding must be validated against the transaction currency. If conversion is performed, store original_amount, original_currency, conversion_rate, and converted_amount; validate converted_amount scale to the target currency.
  • Severity: Reject if inconsistent.
• R11. Payment method constraints
  • Rule: enforce method-specific rules (e.g., cash transactions cannot be negative; prepaid cards cannot create negative balances).
  • Severity: Reject.
• R12. Balance protection (if applicable)
  • Rule: posting the amount must not violate account constraints (e.g., no negative balance for accounts without overdraft).
  • Severity: Reject.
• R13. Total reconciliation (if total present)
  • Rule: subtotal + taxes + fees - discounts must equal total_amount within currency minor unit tolerance.
  • Severity: Reject.

Anomaly and limit monitoring

• R14. Rolling limits
  • Rule: sum of amounts per account/identity within defined windows (e.g., daily, weekly) must not exceed Policy.MaxRollingLimit[currency].
  • Severity: Reject or Flag based on policy.
• R15. Outlier detection
  • Rule: Flag if amount exceeds dynamic threshold (e.g., > P99 of last 90 days for the account or > 3 standard deviations above mean).
  • Severity: Flag.
• R16. Duplicate prevention (amount-level)
  • Rule: Flag potential duplicates when identical amount + currency + merchant + payment method occur within a short time window and same authorization reference.
  • Severity: Flag.

Data quality and formatting at ingestion (for string inputs)

• R17. Canonicalization
  • Rule: strip currency symbols, thousands separators, and locale-specific formatting; convert to canonical numeric before storage.
  • Severity: Reject if canonicalization fails.
• R18. Leading/trailing characters
  • Rule: no leading/trailing spaces; no non-numeric characters except one decimal separator (if using decimal representation).
  • Severity: Reject.

Auditability and lineage

• R19. Provenance
  • Rule: record source_system, capture_method, and transformation steps affecting amount and rounding.
  • Severity: Flag if missing (data quality issue).

Configuration parameters (examples)

• Currency minor units: maintained from ISO 4217; override table for non-ISO assets (e.g., crypto).
• Rounding mode: round_half_up or bankers_rounding; single authoritative setting.
• Max/Min per transaction: per currency, per product, per KYC/risk tier.
• Rolling limits: per account/identity and time window.
• Transaction_type-to-sign map: explicit mapping table.

Example implementation patterns

Preferred storage schema

• Option A (minor units integer):
  • amount_minor_units: BIGINT NOT NULL
  • currency_code: CHAR(3) NOT NULL
  • Constraint: amount_minor_units % 1 = 0 (implicit); scale guaranteed by currency minor unit.
• Option B (decimal fixed-point):
  • amount: DECIMAL(18, s) NOT NULL, where s is determined by currency minor unit; if a single column must store multi-currency, enforce scale on write via application logic and validation triggers.

SQL check constraints (illustrative; adjust for your RDBMS)

• Enforce non-zero for purchase:
  • CHECK (transaction_type <> 'PURCHASE' OR amount_minor_units > 0)
• Enforce sign for refunds:
  • CHECK (transaction_type <> 'REFUND' OR amount_minor_units < 0)
• Per-transaction maximum (example for USD; 2 minor units):
  • CHECK (currency_code <> 'USD' OR ABS(amount_minor_units) <= 10000000) -- e.g., USD 100,000.00

Great Expectations-style rules (illustrative)

• expect_column_values_to_not_be_null: amount
• expect_column_values_to_be_of_type: Decimal/Integer
• expect_column_values_to_be_between: min_value=Policy.MinPerTxn[currency], max_value=Policy.MaxPerTxn[currency], parse dynamically per row
• expect_multicolumn_values_to_satisfy: sign aligned with transaction_type
• custom expectation: decimal_places_equal_currency_minor_unit

Operational notes

• Avoid binary floating-point types; use fixed-point decimal or store minor units as integers.
• Maintain a currency metadata service for minor units and rounding rules; do not hardcode in application code.
• All exceptions must be explicit, logged, and reviewed; default stance is reject on violation.
• Version the policy configuration and capture effective_from dates to ensure reproducible validation across policy changes.

以下为“手机号”数据验证规则，面向数据治理场景，包含字段定义、校验规范、标准化存储、数据质量控制与合规要求。根据业务范围，提供两套规则：仅支持中国大陆手机号（国内场景）与支持全球手机号（国际场景，E.164）。

一、适用范围与标准

• 国内场景（中国大陆手机号）：适用全国移动通信号码（不含座机），采用国家标准号段校验。
• 国际场景（全球手机号）：采用 E.164 编码规则进行结构校验与存储。

二、字段定义与元数据

• 数据名称：mobile_phone_number
• 数据类型：字符串（String）
• 字段长度：
  • 国内存储（本地格式）：11 位
  • 国际存储（E.164）：最多 16 个字符（包含前导“+”，最多 15 位数字）
• 字段敏感级别：个人敏感信息（PII）
• 主键/唯一性：按规范化后（canonical）的 E.164 形式建立唯一约束（防重复）
• 允许值域：按下述校验规则

三、校验规则 A. 通用基础规则（输入层）

• 非空校验：不能为空或仅空白字符。
• 字符集校验：仅允许数字、可选的前导“+”，输入中的空格、连字符、括号等展示性字符必须在标准化阶段移除，不参与存储。
• 长度初筛：去除非数字/格式字符后，数字长度应在 7–15 位之间（国际），或恰为 11 位（国内）。

B. 中国大陆手机号校验规则（国内场景）

• 结构规则：必须为 11 位数字，正则：^1[3-9]\d{9}$
  • 说明：以 1 开头，第二位范围 3–9，后续 9 位为数字。该模式覆盖主流运营商与虚拟运营商号段。
• 禁止包含国内拨号前缀（如 0、(0) 等）、分隔符；输入层允许存在分隔符但标准化时移除。
• 规范化存储：
  • 国内本地格式：存 11 位（例：13800000000）
  • 国际统一格式（推荐）：存 E.164（例：+8613800000000）
• 业务校验（可选强化）：发送一次性验证码（OTP）或语音回拨验证，以确认可达性与活跃性。

C. 全球手机号校验规则（国际场景，E.164）

• 结构规则：国际表示正则：^+[1-9]\d{1,14}$
  • 说明：前导“+”，其后为国家码（不能以 0 开头），总数字长度最多 15 位；不包含国家内的拨号前缀或分隔符。
• 标准化要求：
  • 移除空格、连字符、括号等展示性字符。
  • 将“00”国际接入码转换为“+”（例如 0044123456789 → +44123456789）。
  • 禁止保留国家内长途/国内前缀（如 0）。
• 可选国家级校验（增强）：在已知国家码下，校验该国的国家重要号码（NSN）长度边界与已知移动号段前缀（需维护国家规则表）；注意该校验需定期维护更新。

四、标准化与存储策略

• 规范化流程（输入→存储）：
  1. Trim 去除首尾空白。
  2. 移除所有非数字字符，保留可选前导“+”；将“00”替换为“+”。
  3. 若为国内场景且无国家码：在通过国内正则校验后，生成 E.164 表示为 +86 + 本地 11 位。
  4. 再次按目标规则校验（国内或国际）。
  5. 以 E.164 形式作为 canonical 存储，并用于唯一性与比对。
• 展示层可按区域格式化，但数据库始终存 canonical（E.164）。
• 索引与去重：对 canonical 字段建立唯一索引；新增或更新前进行去重检查。

五、数据质量管理

• 质量维度与度量：
  • 完整性：手机号非空率 ≥ 指标阈值（如 99%）。
  • 有效性：通过规则校验的比例 ≥ 阈值（如 98%）。
  • 一致性：存储统一为 E.164；不同系统间一致率 ≥ 阈值。
  • 唯一性：重复率 ≤ 阈值（如 ≤ 0.5‰）。
  • 可达性：验证码送达成功率、退回率监控。
• 异常处理：
  • 失败原因分类（空值、非法字符、长度不符、号段不符、E.164 不合规）。
  • 生成标准错误码与友好提示，支持数据修复工作流。
• 变更管理：国家号段、规则库定期审查与更新；版本化规则并记录生效日期。

六、合规与安全要求

• 分类分级：标为 PII，纳入个人信息保护与访问控制策略。
• 存储与传输：使用加密传输（TLS），静态加密或字段级加密（视风险等级）。
• 最小化与目的限制：仅为联系与认证目的收集；超目的使用需评估与授权。
• 脱敏与展示：日志、报表、测试数据中进行部分掩码（如 +86138****0000）。
• 保留与删除：按数据保留政策定期清理未验证或过期手机号；满足数据主体删除请求。
• 审计与合规：记录采集、验证、变更与访问审计；满足适用法律法规（如数据跨境传输合规）。

七、实现示例（规则表达）

• 国内手机号正则（输入层）：^1[3-9]\d{9}$
• 国际 E.164 正则（canonical 层）：^+[1-9]\d{1,14}$
• 伪代码流程（简化）：
  • 输入 s
  • s = trim(s)
  • 若 s 以 "00" 开头 → s = "+" + s[2:]
  • 移除除数字与前导“+”外的字符
  • 若国内模式：
    • 若 s 匹配 ^1[3-9]\d{9}$ → canonical = "+86" + s
    • 否则失败
  • 若国际模式：
    • 若 s 匹配 ^+[1-9]\d{1,14}$ → canonical = s
    • 否则失败
  • 写入 canonical；建立唯一索引；必要时触发 OTP 验证

八、测试用例（示例）

• 有效（国内）：13800000000 → +8613800000000
• 有效（国际）：+441234567890 → +441234567890
• 标准化："(+86) 138-0000-0000" → +8613800000000
• 无效：123456、+012345、+86 13800000000（含空格且未规范化时）、1A800000000（含字母）

以上规则可直接纳入数据标准与校验服务，结合数据质量监控与合规控制形成闭环。根据组织业务范围选择国内或国际模式，或并行支持并通过 canonical 存储确保一致性与可用性。