マニュアルと自動支払い

1）概念的なフレーム

自動支払い-「パス/拒否/エスカレート」の決定は、ルールとスコアに基づいて自動的に行われ、オペレータの参加なしに廊下に送信されます。

手作業による支払い-人間検証（Fin。 operator/risk analyst）は、返品/返品前にリクエストを確認またはキャンセルします。

2）モード選択基準

Autoがデフォルトの場合

同じメソッドとソースへのリターンが満たされました。
ND ≥ 0（負の純預金なし）。
KYCレベル≥ L1、アクティブなRGロックなし。
リスクレート<しきい値、地理的競合なし（IP≈KYC≈SIM）。
セグメントの事前承認された閾値≤の合計。
方法/回廊-低リターンで瞬時/信頼性。
新鮮なチャージバック/乱用信号はありません。

「manual」がデフォルトの場合

SoF/SoWが必要です（しきい値/信号）。
POP/Sank Phase（ファジーヒット）または物議を醸すドキュメント。
GEO紛争、疑わしいマルチアカウント/世帯。
速度/量の異常（多くのアプリケーション、大量）。
歴史のない新しい小道具への結論。
FX仲裁シナリオ、非標準の廊下（SWIFT）。
ルールの例外と原因不明の返品。

3）長所/短所

4）ハイブリッドパイプラインアーキテクチャ

1.事前チェック：同じ方法、ND、 RG/KYC、制裁。
2.リスクスコアリング：支払い/デバイス/行動/geo/fxの兆候。
3.Decisioner： 'AUTO_PASS/ MANUAL_REVIEW/DENY'。
4.キュー：SLA優先順位を持つ手動キュー、廊下への自動ルータ。
5.オーケストレーション：コスト/ETA/制限による廊下（インスタント→高速→標準）の選択。
6.財務省/FX：事前資金、プール制限、スリッページガード。
7.和解：ステータス、リターン/リバース、再ルーティング/リファンド。
8.観測可能性：タイムライン、p95/p99、 backlog、違反アラート。

5）ポリシー（擬似DSL）

yaml policy: "payouts_auto_manual_v2"
eligibility:
same_method: true nd_min: 0 kyc_min: L1 routing:
cascade:
- corridor: "INSTANT" when: risk_score < 0. 5 and amount <= preapproved_limit
- corridor: "FAST_A2A" when: risk_score < 0. 65
- corridor: "STANDARD_SEPA" when: else manual_review:
triggers:
- risk_score >= 0. 65
- geo_conflict_score >= 2
- new_beneficiary == true and amount > new_beneficiary_cap
- sanctions_fuzzy_hit == true
- velocity_24h_payouts > 3 or amount_24h > segment_cap
- returns_last_30d >= 1 deny:
rules:
- self_excluded == true
- nd_total < 0 and allow_nd_withdrawal == false limits:
preapproved_limit:
LOW_RISK: {EUR: 2000}
MID_RISK: {EUR: 500}
sla:
auto_p95_minutes: 30 manual_p95_hours: 8 audit:
store_decision_tree: true store_feature_snapshot: true

6）手動チェックキューと優先順位

1.期限切れのSLAによる上級額。

2.同方法&ND ≥ 0（確認時にクイックリリース）。

3.1人のプレイヤーのマルチチケット（下のチャーン/アピール）。

4.ネットワークの劣化を伴うインスタント回廊（高速ハングアップまたは解像度）。

5.残りは……

キュー管理SLA：ソリューション'≤ 4-8時間'のターゲットp95（ライセンス/市場依存）。
ツール：ドキュメントの自動サブコレクション、チェックリスト、応答マクロ「、ノートで承認」、「部分リリース」。

7） UXとコミュニケーション

自動分岐：ETAとステータス（「Initiated」、 「Credited」）を表示します。
手動分岐：正直に予想されるウィンドウ（しきい値）と必要なもの（ドキュメント/チェックのリスト）を教えてください。
エスカレーション：SLAを離れるときの通知、メソッドを変更する提案（同じ方法/NDに違反しない場合）。
詳細履歴：将来の自動支払いのための「検証済み」受信者とマークされています。

8）データモデル

sql payout. timeline (
payout_id PK, user_id, amount_minor BIGINT, currency TEXT,
method TEXT, corridor TEXT, provider TEXT, iso2 TEXT,
nd_snapshot NUMERIC, same_method_ok BOOLEAN,
risk_score NUMERIC, decision TEXT, -- AUTO_PASS    MANUAL    DENY reason_codes TEXT[], reviewer TEXT,
t_request TIMESTAMP, t_precheck_ok TIMESTAMP, t_risk_ok TIMESTAMP,
t_decided TIMESTAMP, t_initiated TIMESTAMP, t_posted TIMESTAMP, t_available TIMESTAMP,
status TEXT, meta JSONB
);

review. queue (
ticket_id PK, payout_id FK, priority INT, state TEXT, assignee TEXT,
created_at TIMESTAMP, picked_at TIMESTAMP, resolved_at TIMESTAMP, sla_deadline TIMESTAMP
);

risk. features_snapshot (
payout_id FK, payload JSONB, created_at TIMESTAMP
);

9） SQLテンプレート

9.1.自動/手動/障害とそのTTWの共有

sql
SELECT decision,
COUNT() AS cnt,
100. 0 COUNT() / SUM(COUNT()) OVER () AS share_pct,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (COALESCE(t_available, t_decided) - t_request))) AS p95_sec
FROM payout. timeline
WHERE t_request BETWEEN:from AND:to
GROUP BY decision;

9.2.手動キューバックログとSLA遅延

sql
SELECT
COUNT() FILTER (WHERE state='OPEN') AS open_tickets,
COUNT() FILTER (WHERE sla_deadline < now() AND state IN ('OPEN','IN_PROGRESS')) AS sla_breaches
FROM review. queue;

9.3.自動決済-廊下に沿って違反

sql
SELECT corridor,
100. 0 COUNT() FILTER (WHERE EXTRACT(EPOCH FROM (t_available - t_request)) >:p95_target_sec) / NULLIF(COUNT(),0) AS breach_pct
FROM payout. timeline
WHERE decision='AUTO_PASS' AND status='SUCCESS'
AND t_request BETWEEN:from AND:to
GROUP BY 1 ORDER BY breach_pct DESC;

9.4.マニュアル→許可された変換

sql
SELECT
100. 0 COUNT() FILTER (WHERE status IN ('SUCCESS','INITIATED')) / NULLIF(COUNT(),0) AS manual_approve_rate
FROM payout. timeline
WHERE decision='MANUAL' AND t_decided BETWEEN:from AND:to;

10）メトリクスとダッシュボード

オートレート％：オートラインでの支払いのシェア。
マニュアル承認％/拒否％、マニュアルp95 TAT（決定時間）。
TTW P95/p99 は/corridor/provider/geo決定します。
SLA違反％（自動および手動）。
リターン/リバース％と返済後の返済のシェア。
支店や廊下に沿って支払いごとにコスト。
アプリケーション間のND <0シェア。
キューヘルス：オープン、進行中、休憩、平均待ち。
ペイアウトとCSATとモードをComplaint/1kします。

11）アラート

手動バックログスパイク：'open_tickets'>しきい値または'manual p95 TAT'>SLA。
廊下/プロバイダの自動P95違反。
code/bank/geoでサージを返します。
アプリケーションのND負のスパイク。
ポリシードリフト：固定ソリューション/機能スナップショットなしでの支払い。
新しい有益なリスク：新しい受取人に対するマニュアルの割合が高い。

12）インシデントプレイブック

A。ハンドサージ（TTWを阻害）

1.X和までの低リスクのセグメントの事前承認を含める。
2.レビューの容量を増やす（ロングデイ、シフトを移動）。
3.安全なGEO/メソッドでMANUALのrisk_scoreしきい値を一時的に上げます。

B。 Auto corridor degradation （p95）

1.代替通路にカスケード、txnごとの制限を削減します。
2.ETAユーザー、PSPチケット/銀行を更新します。
3.Post-mortem：ルーティングウェイトを調整します。

C。 Waveは新しい小道具のために戻ります

1.手動確認の前に「新しい」受信者を自動ブロックします。
2.保存されたプロップ/ソースをプレーヤーに提供します。
3.ゲームウォレットとCTAへの自動払い戻し「方法を選択」。

13）経済とトレードオフ

Autoはオペレーティングシステムのコストを削減し、CSAT/保持を増加させますが、スコアリング/ルール/テレメトリへの投資が必要です。
手動式はより高価ですが、まれに大きな損失を減らし、規制保護にとって重要です。
私たちはバランスポイントを探しています：低リスクのセグメントとインスタント回廊のための最大の車；マニュアル-エッジケース用。

14） A/Bテスト

しきい値'risk_score'、承認前の制限、カスケード内の廊下の優先度。
マニュアルブランチの著作権とETA。
ガードレール：％、CBR bps、手動p95 TAT、 CSAT、 Complaints/1kを返します。

15）ベストプラクティス（短い）

1.ND ≥ 0、 same-method、 KYC L1+、低量および検証済みの詳細のデフォルトオート。
2.Policy-as-code+機能/意思決定ログ、再現性。
3.コスト/ETA/健康、自動フェイルオーバーの廊下のカスケード。
4.オペレータのSLA優先キューとチェックリスト。
5.両方のブランチの透明なETAとステータス。
6.事前資金/プール制限、FXガード。
7.p95/p99メトリックとtail/return/backlogアラート。
8.ポストインシデントと定期的なスコアリング/ルールチューニング。

16）実装チェックリスト

• AUTO/MANUAL/DENYとversioning triger matrix。
• セグメント別のスコアと「事前承認」制限。
• 同一方法/ND/KYC/RG/制裁前検査。
• キューと優先順位、SLAと役割。
• 廊下と健康飼料のカスケード、フェイルオーバー。
• データモデルとタイムライン、機能/ソリューションのスナップショット。
• TTW/SLA/returns/backlogによるダッシュボードとアラート。
• プレイブック：劣化、リターンの波、マニュアルの成長。
• A/BとReturn/CB Data Freeze
• 定期的なライセンス/ポリシーのコンプライアンス監査。

概要

「手動対自動支払い」-どちらか一方の選択ではなく、層別化されたシステム：自動-強力なテレメトリを持つ予測可能な安全なシナリオのための；マニュアル-狭く、危険で、規制に敏感なケースのために。ルールをコードとして正式化し、p95/p99とbacklogを測定し、通路のカスケードと透明なETAを維持します。