KYC/AML 客戶日誌後端

KYC/AML 客戶日誌後端模板
身份檢查、風險評分和 PEP 篩查日誌

Q: KYC/AML 客戶日誌團隊如何在不重建電子郵件線程的情況下證明批准和例外？

這是一個用於跟蹤客戶入職的後端架構和 API：身份驗證、風險評分、PEP 篩查日誌和工作人員審查備註。

Q: 客戶註冊、身份驗證記錄、風險評分之間的哪些關係使 KYC/AML 客戶日誌審計更容易敘述？

它包括客戶（fullName、customerId、segment、onboardingState）、IdentityCheck（client、idType、documentNumber、verifiedAt、verifiedBy、result）、RiskAssessment（client、score、riskLevel、rationale、reviewer、assessedAt）、PEPScreening（client、listSource、matchStatus、screenedAt、notes）、LogEntry（client、eventType、notes、createdBy、createdAt），以及 ER 圖、API 遊樂場和 AI Agent 提示。

Q: 我們如何擴展 KYC/AML 客戶日誌工作流程以進行多步批准，而不破壞歷史？

Back4app 提供管理數據庫、身份驗證、實時查詢和靈活的架構，因此您可以運行客戶驗證、風險評分和篩查日誌，而無需維護自己的後端。

Q: 我該如何使用 Flutter 查詢客戶日誌？

使用 Client、IdentityCheck 和 PEPScreening 類來提取當前的審核隊列並在您的 Flutter UI 中顯示驗證狀態。

Q: 我該如何管理 Next.js 的審核人員訪問權限？

使用服務器操作為 IdentityCheck 或 RiskAssessment 創建 Parse 對象，並將活動審核人員指針包含在內，然後在 Cloud Code 中驗證變更。

Q: React Native 是否可以離線緩存篩檢日誌？

可以。啟用本地數據存儲並固定 Client 和 PEPScreening 結果，以便協調員在網絡掉線時仍然可以繼續工作。

Q: 我該如何防止未經授權的變更客戶驗證數據？

在 IdentityCheck 和 RiskAssessment 的 Cloud Code beforeSave 中，強制執行審核人員檢查，並拒絕未經批准的用戶的寫入。

Q: 在 Android 上顯示客戶日誌的最佳方法是什麼？

查詢 Client、IdentityCheck、RiskAssessment 和 PEPScreening 類以顯示活動審核隊列，然後在 LogEntry 更新到達時刷新。

在 Back4app 上的生產就緒 KYC/AML 客戶日誌後端，擁有客戶記錄、身份驗證、風險評分和 PEP 篩查日誌。包括 ER 圖、數據字典、JSON 架構、API 投玩具和一個 AI 代理 提示以便迅速啟動。

與 AI 代理一起構建選擇您的技術

重點摘要

此模板為您提供了一個具身份驗證、風險評分和篩檢日誌的 KYC/AML 客戶日誌後端，使操作團隊能夠從一個結構化的真實來源進行工作。

客戶身份日誌 — 對客戶和身份檢查對象進行建模，使每個驗證步驟與指定的客戶資料相關聯。
風險評分追蹤 — 追蹤具有明確分數、級別和審核人員欄位的風險評估條目，以便於審核的決策。
PEP 篩檢歷史 — 記錄每個重新篩檢事件的 PEP 篩檢結果和匹配備註。
操作審查隊列 — 為經理和協調員提供一個地方以監控 logStatus、evidenceStatus 和後續需求。
跨平台合規後端 — 通過相同的 REST 和 GraphQL API 為客戶日誌和篩選工作流程提供網頁、移動和內部工具。

什麼是 KYC/AML 客戶日誌範本？

如果 KYC/AML 客戶日誌的簽署是非正式的，當六個月後出現問題時，你將無法證明職責分離。小延遲會迅速累積。使用 Client、IdentityCheck、RiskAssessment、PEPScreening 和 LogEntry 作為 Back4app 上的結構化合規原語，以確保 KYC/AML 客戶日誌工作流程在不同地點和班次之間保持一致。此架構涵蓋 Client（fullName、customerId、segment）、IdentityCheck（client、idType、documentNumber、verifiedAt）、RiskAssessment（client、score、riskLevel、reviewer）、PEPScreening（client、listSource、matchStatus、screenedAt）和 LogEntry（client、eventType、notes、createdBy），並內置授權和審查控制。連接你的首選前端，並加速交付。

最佳適用於：

KYC/AML 操作儀表板客戶驗證門戶風險評分工作隊列PEP篩查日誌系統內部合規工具團隊為受監管的工作流程選擇 BaaS

這個 KYC/AML 客戶日誌後端的組織方式

移動工作團隊和後端辦公室員工在 KYC/AML 客戶日誌中看到不同的現實切片；產品的工作就是將這些切片縫合在一起，而不進行責備遊戲。

首先查看 Client、IdentityCheck 和 RiskAssessment，然後打開堆棧卡以查看特定於 SDK 的註釋和集成模式。

核心 KYC/AML 客戶登錄功能

這個中心的每一張技術卡都使用相同的 KYC/AML 客戶日誌結構，包括 Client、IdentityCheck、RiskAssessment、PEPScreening 和 LogEntry。

客戶註冊表

客戶包含全名、客戶ID、細分和啟用狀態。

身份驗證記錄

IdentityCheck 將客戶與 idType、documentNumber 和 verifiedAt 連結。

風險評分

風險評估追蹤分數、風險級別、理由和審核者。

政治人物篩查日誌

政治人物篩查保存列表來源、匹配狀態、篩查時間和備註。

事件日誌記錄

日誌條目記錄每次客戶行動的事件類型、備註和創建者。

為什麼要使用 Back4app 建立您的 KYC/AML 客戶登錄後端？

Back4app 為您提供客戶、身份、風險和篩選的基本功能，讓管理人員可以專注於審核決策，而不是後端管道。

•客戶和身份追蹤: Client 類和 IdentityCheck 指針將護照、身份證或稅號檢查與特定客戶保持關聯。
•風險評分及審核上下文: RiskAssessment 儲存分數、風險等級和審核人，以便分析人員可以解釋為什麼一個客戶的風險是低、中或高。
•PEP 篩查日誌和回放: PEPScreening 和 LogEntry 保存每次篩查運行、匹配狀態和後續註釋，以供後續審查。

從一個後端合約運行客戶驗證、評分和篩查，跨越網頁和移動工具。

核心好處

一個客戶日誌後端，幫助合規團隊快速行動，同時不失去審計痕跡。

更快速的客戶審查接收

從完整的 Client 和 IdentityCheck 結構開始，而不是從頭設計驗證欄位。

清晰的風險背景

使用 RiskAssessment 分數、風險等級和理由來解釋為什麼客戶需要更多審查。

一次性查看篩查歷史

將 PEPScreening 結果存儲在相同的客戶指標下，以便於比較重複檢查。

符合審計的行動追蹤

LogEntry 為每次手動更正、升級或驗證更新保留事件類型和備註。

一致的訪問控管

使用 ACL 和 CLP 規則來限制客戶端日誌、篩選和審閱者備註僅限於經批准的員工。

AI 啟動工作流程

通過一個結構化提示快速生成後端框架和集成指南。

準備啟動您的 KYC/AML 客戶日誌應用程式嗎？

讓 Back4app AI 代理支撐您的 KYC/AML 客戶日誌後端，並從一個提示生成身份、風險和篩選日誌流程。

與 AI 代理一起構建嘗試API遊樂場

免費開始 — 每月50個AI代理提示，無需信用卡

技術棧

此KYC/AML客戶登錄後端模板包含所有內容。

前端

13+ 程式語言

後端

Back4app

資料庫

MongoDB

認證

內建認證 + 會話

API

REST 和 GraphQL

即時

Live Queries

ER圖

KYC/AML 客戶日誌模式的實體關係模型。

實體關係圖

查看圖表來源

Mermaid

erDiagram
    Analyst ||--o{ Client : "owner"
    Analyst ||--o{ VerificationLog : "verifiedBy"
    Analyst ||--o{ RiskAssessment : "assessedBy"
    Analyst ||--o{ PepScreening : "screenedBy"
    Analyst ||--o{ ActivityNote : "author"
    Client ||--o{ VerificationLog : "client"
    Client ||--o{ RiskAssessment : "client"
    Client ||--o{ PepScreening : "client"
    Client ||--o{ ActivityNote : "client"

    Analyst {
        String objectId PK
        String username
        String email
        String password
        String role
        Date createdAt
        Date updatedAt
    }

    Client {
        String objectId PK
        String fullName
        String externalRef
        Date dateOfBirth
        String governmentIdLast4
        String riskTier
        String ownerId FK
        Date createdAt
        Date updatedAt
    }

    VerificationLog {
        String objectId PK
        String clientId FK
        String verifiedById FK
        String idType
        String idStatus
        Date verificationDate
        String notes
        Date createdAt
        Date updatedAt
    }

    RiskAssessment {
        String objectId PK
        String clientId FK
        String assessedById FK
        Number riskScore
        String riskLevel
        String scoringRule
        String reviewStatus
        Date createdAt
        Date updatedAt
    }

    PepScreening {
        String objectId PK
        String clientId FK
        String screenedById FK
        String screeningSource
        String matchStatus
        Number matchScore
        Date screenedAt
        Date createdAt
        Date updatedAt
    }

    ActivityNote {
        String objectId PK
        String clientId FK
        String authorId FK
        String subject
        String body
        String noteType
        Date createdAt
        Date updatedAt
    }

驗證流程

登錄、客戶查找、身份驗證、風險評分和PEP篩檢日誌的典型運行流程。

實體關係圖

查看圖表來源

Mermaid

sequenceDiagram
  participant Analyst
  participant App as KYC/AML Client Log App
  participant Back4app as Back4app Cloud

  Analyst->>App: Sign in to review client logs
  App->>Back4app: POST /login
  Back4app-->>App: Session token

  Analyst->>App: Open client register
  App->>Back4app: GET /classes/Client?include=owner&order=-updatedAt
  Back4app-->>App: Client list

  Analyst->>App: Save ID verification log
  App->>Back4app: POST /classes/VerificationLog
  Back4app-->>App: VerificationLog objectId

  Analyst->>App: Run risk scoring and PEP screening
  App->>Back4app: POST /classes/RiskAssessment
  App->>Back4app: POST /classes/PepScreening
  Back4app-->>App: Assessment and screening results

  App->>Back4app: GET /classes/ActivityNote?include=client,author
  Back4app-->>App: Activity notes

  Back4app-->>App: Live updates for client log changes

資料字典

KYC/AML 客戶日誌架構中每個類別的完整欄位級參考。

欄位	類型	描述	必填
objectId	String	Auto-generated unique identifier	自動
username	String	Login name used by KYC/AML staff
email	String	Work email address
password	String	Hashed password (write-only)
role	String	Staff role such as manager, coordinator, or reviewer
createdAt	Date	Auto-generated creation timestamp	自動
updatedAt	Date	Auto-generated last-update timestamp	自動

7 欄位在 Analyst 中

安全性與權限

ACL 和 CLP 策略如何保護客戶、驗證步驟、風險評分和篩檢日誌。

僅限員工的審核訪問

只有獲批准的經理和協調員可以創建或編輯客戶、身份檢查、風險評估和PEP篩查條目。

客戶日誌完整性

使用雲端代碼驗證documentNumber、score、matchStatus和reviewer，然後再保存更改。

範圍讀取權限

限制讀取，使員工只能看到分配給他們的團隊或隊列的客戶日誌和篩查項目。

架構 (JSON)

準備好複製到Back4app的原始JSON架構定義或用作實施參考。

JSON

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

{
  "classes": [
    {
      "className": "Analyst",
      "fields": {
        "objectId": {
          "type": "String",
          "required": false
        },
        "username": {
          "type": "String",
          "required": true
        },
        "email": {
          "type": "String",
          "required": true
        },
        "password": {
          "type": "String",
          "required": true
        },
        "role": {
          "type": "String",
          "required": true
        },
        "createdAt": {
          "type": "Date",
          "required": false
        },
        "updatedAt": {
          "type": "Date",
          "required": false
        }
      }
    },
    {
      "className": "Client",
      "fields": {
        "objectId": {
          "type": "String",
          "required": false
        },
        "fullName": {
          "type": "String",
          "required": true
        },
        "externalRef": {
          "type": "String",
          "required": true
        },
        "dateOfBirth": {
          "type": "Date",
          "required": false
        },
        "governmentIdLast4": {
          "type": "String",
          "required": false
        },
        "riskTier": {
          "type": "String",
          "required": true
        },
        "owner": {
          "type": "Pointer",
          "required": true,
          "targetClass": "Analyst"
        },
        "createdAt": {
          "type": "Date",
          "required": false
        },
        "updatedAt": {
          "type": "Date",
          "required": false
        }
      }
    },
    {
      "className": "VerificationLog",
      "fields": {
        "objectId": {
          "type": "String",
          "required": false
        },
        "client": {
          "type": "Pointer",
          "required": true,
          "targetClass": "Client"
        },
        "verifiedBy": {
          "type": "Pointer",
          "required": true,
          "targetClass": "Analyst"
        },
        "idType": {
          "type": "String",
          "required": true
        },
        "idStatus": {
          "type": "String",
          "required": true
        },
        "verificationDate": {
          "type": "Date",
          "required": true
        },
        "notes": {
          "type": "String",
          "required": false
        },
        "createdAt": {
          "type": "Date",
          "required": false
        },
        "updatedAt": {
          "type": "Date",
          "required": false
        }
      }
    },
    {
      "className": "RiskAssessment",
      "fields": {
        "objectId": {
          "type": "String",
          "required": false
        },
        "client": {
          "type": "Pointer",
          "required": true,
          "targetClass": "Client"
        },
        "assessedBy": {
          "type": "Pointer",
          "required": true,
          "targetClass": "Analyst"
        },
        "riskScore": {
          "type": "Number",
          "required": true
        },
        "riskLevel": {
          "type": "String",
          "required": true
        },
        "scoringRule": {
          "type": "String",
          "required": true
        },
        "reviewStatus": {
          "type": "String",
          "required": true
        },
        "createdAt": {
          "type": "Date",
          "required": false
        },
        "updatedAt": {
          "type": "Date",
          "required": false
        }
      }
    },
    {
      "className": "PepScreening",
      "fields": {
        "objectId": {
          "type": "String",
          "required": false
        },
        "client": {
          "type": "Pointer",
          "required": true,
          "targetClass": "Client"
        },
        "screenedBy": {
          "type": "Pointer",
          "required": true,
          "targetClass": "Analyst"
        },
        "screeningSource": {
          "type": "String",
          "required": true
        },
        "matchStatus": {
          "type": "String",
          "required": true
        },
        "matchScore": {
          "type": "Number",
          "required": true
        },
        "screenedAt": {
          "type": "Date",
          "required": true
        },
        "createdAt": {
          "type": "Date",
          "required": false
        },
        "updatedAt": {
          "type": "Date",
          "required": false
        }
      }
    },
    {
      "className": "ActivityNote",
      "fields": {
        "objectId": {
          "type": "String",
          "required": false
        },
        "client": {
          "type": "Pointer",
          "required": true,
          "targetClass": "Client"
        },
        "author": {
          "type": "Pointer",
          "required": true,
          "targetClass": "Analyst"
        },
        "subject": {
          "type": "String",
          "required": true
        },
        "body": {
          "type": "String",
          "required": true
        },
        "noteType": {
          "type": "String",
          "required": true
        },
        "createdAt": {
          "type": "Date",
          "required": false
        },
        "updatedAt": {
          "type": "Date",
          "required": false
        }
      }
    }
  ]
}

建立AI代理

使用 Back4app AI 代理從這個模板生成一個真正的 KYC/AML 客戶日誌應用，包括前端、後端、身份驗證、客戶驗證、風險評估和篩查日誌流程。

Back4app AI 代理

準備好構建

在 Back4app 上使用這個精確的架構和行為創建 KYC/AML 客戶日誌應用後端。

架構：
1. 用戶（使用 Back4app 內建）：用戶名、電子郵件、密碼；objectId、createdAt、updatedAt（系統）。
2. 客戶：全名（字符串，必填）、客戶 ID（字符串，必填）、細分（字符串，必填）、入職狀態（字符串，必填）；objectId、createdAt、updatedAt（系統）。
3. 身份檢查：客戶（指向客戶的指標，必填）、身份類型（字符串，必填）、文件號碼（字符串，必填）、核實時間（日期，必填）、核實者（指向用戶的指標，必填）、結果（字符串，必填）；objectId、createdAt、updatedAt（系統）。
4. 風險評估：客戶（指向客戶的指標，必填）、分數（數字，必填）、風險級別（字符串，必填）、理由（字符串，必填）、審核人（指向用戶的指標，必填）、評估時間（日期，必填）；objectId、createdAt、updatedAt（系統）。
5. PEP篩查：客戶（指向客戶的指標，必填）、列表來源（字符串，必填）、匹配狀態（字符串，必填）、篩查時間（日期，必填）、備註（字符串）；objectId、createdAt、updatedAt（系統）。
6. 日誌條目：客戶（指向客戶的指標，必填）、事件類型（字符串，必填）、備註（字符串，必填）、創建者（指向用戶的指標，必填）、創建時間（日期，必填）；objectId、createdAt、updatedAt（系統）。

安全性：
- 只有經批准的工作人員才能創建或編輯客戶日誌。使用雲代碼進行驗證。

身份驗證：
- 註冊、登錄、登出。

行為：
- 列出客戶、創建身份檢查、記錄風險評估和保存 PEP 篩查日誌。

交付：
- 具有架構、ACL、CLP 的 Back4app 應用；用於客戶日誌、驗證、評分和篩查工作流程的前端。

按下下面的按鈕以打開代理，並預填此模板提示。

這是沒有技術後綴的基本提示。您可以隨後調整生成的前端堆棧。

幾分鐘內部署每月 50 次免費提示不需要信用卡

API 操作空間

嘗試對 KYC/AML 客戶日誌架構使用 REST 和 GraphQL 端點。響應使用模擬數據，並不需要 Back4app 帳戶。

載入遊樂場中…

使用與此模板相同的架構。

選擇您的技術

展開每張卡片以查看如何將 Client、IdentityCheck 和 RiskAssessment 與您選擇的技術棧整合。

您將獲得每項技術的收益

每個技術棧使用相同的 KYC/AML 客戶日誌架構和 API 合約。

統一的客戶日誌結構

在一個架構中管理客戶、身份檢查、風險評估、PEP篩查和登錄條目。

身份驗證工作流程

捕獲每個客戶檢查的 idType、documentNumber、verifiedAt 和 verifiedBy。

審查隊列的風險評分

使用分數、風險級別和理由將客戶路由到適當的審核人員。

PEP 篩查日誌以供審計跟蹤

在每次篩查運行中保留 listSource、matchStatus 和 screenedAt。

REST/GraphQL API 供操作團隊使用

通過靈活的 API 集成儀表板、內部工具和移動審核應用。

KYC/AML框架比較

比較所有支持的技術中的設置速度、SDK風格和AI支持。

框架	設置時間	KYC/AML 優勢	SDK 類型	AI 支援
Flutter	約 5 分鐘	在移動端和網頁上進行客戶審查的單一代碼基礎。	類型化 SDK	完整
React	少於 5 分鐘	快速的網頁儀表板，用於驗證隊列。	類型化 SDK	完整
React 原生	約 3–7 分鐘	跨平台的移動應用程式，用於現場驗證。	類型化 SDK	完整
Next.js	快速 (5 分鐘) 設定	伺服器渲染操作控制台，供審查團隊使用。	類型化 SDK	完整
JavaScript	約 3–5 分鐘	輕量級瀏覽器整合用於客戶日誌。	類型化 SDK	完整
Android	約 5 分鐘	適用於合規人員的原生 Android 應用程式。	輸入型 SDK	完整
iOS	少於 5 分鐘	適用於審查和篩查工作的原生 iOS 應用程式。	輸入型 SDK	完整
Vue	約 3–7 分鐘	Reactive 網頁使用者介面用於案件處理。	輸入型 SDK	完整
Angular	快速（5分鐘）設置	企業操作應用程式，用於KYC/AML團隊。	輸入式SDK	完整
GraphQL	少於2分鐘	靈活的GraphQL API，用於嵌套客戶審查查詢。	GraphQL API	完整
REST API	快速（2分鐘）設置	REST API整合，用於篩檢和日誌服務。	REST API	完整
PHP	約3分鐘	客戶端日誌工具的伺服器端 PHP 後端。	REST API	完整
.NET	大約 3–7 分鐘	符合規範系統的 .NET 後端。	類型化 SDK	完整

設置時間反映了從專案啟動到使用此模板架構的第一個客戶、身份檢查或 PEPScreening 查詢的預期持續時間。

常見問題

有關如何使用此模板構建 KYC/AML 客戶日誌後端的常見問題。

KYC/AML 客戶日誌團隊如何在不重建電子郵件線程的情況下證明批准和例外？

客戶註冊、身份驗證記錄、風險評分之間的哪些關係使 KYC/AML 客戶日誌審計更容易敘述？

我們如何擴展 KYC/AML 客戶日誌工作流程以進行多步批准，而不破壞歷史？

我該如何使用 Flutter 查詢客戶日誌？

我該如何管理 Next.js 的審核人員訪問權限？

React Native 是否可以離線緩存篩檢日誌？

我該如何防止未經授權的變更客戶驗證數據？

在 Android 上顯示客戶日誌的最佳方法是什麼？

全球開發者信賴的選擇

使用 Back4app 模板，加入快速交付 KYC/AML 客戶日誌產品的團隊

準備好構建您的 KYC/AML 客戶日誌應用程式了嗎？

在幾分鐘內開始您的客戶日誌專案。無需信用卡。

選擇技術

KYC/AML 客戶日誌後端模板身份檢查、風險評分和 PEP 篩查日誌