1. Bản đồ toàn cảnh trong 60 giây#

Toàn bộ tài liệu có thể nén thành 7 tầng dữ liệu:

1. Kênh giao dịch: ATM/POS, Mobile, CMS, Open API, SWIFT.
2. Kiểm soát trước giao dịch: KYC/AML, Watchlist, hạn mức, trạng thái tài khoản.
3. Core nghiệp vụ: Customer, Deposit, Loan, FX/Trade, Treasury.
4. Kế toán giao dịch: Master/History → Slip → Voucher → General Ledger.
5. Chốt sổ cuối ngày: Accrual, FTP, Netting, Reconciliation, EOD Batch.
6. Kho dữ liệu: Basic Mart → Integration Mart → Detailed Mart → KPI/Report Mart.
7. Quản trị: PMS/Profitability, Risk/Basel/ALM, báo cáo quản trị và pháp lý.

Luồng nhớ duy nhất#

Mermaid source (tùy chọn)

Câu thần chú:

Giao dịch phải có ID để truy vết, dữ liệu phải có grain rõ ràng, kế toán phải DR = CR, batch phải idempotent, mart phải đối soát, báo cáo phải không nhân bản dữ liệu.

2. Thống kê và làm sạch tài liệu nguồn#

• Tài liệu nguồn khoảng 43.500 từ, 2.617 dòng, hơn 265 KB.
• Có 37 khối ROM, trong đó:
  • 2 khối là template/phương pháp học.
  • 2 cặp nội dung gần như trùng: AML và Accounting/Closing.
  • 2 cặp Deposit có nội dung chồng lấn nhưng bản sau chi tiết hơn.
• Sau khi hợp nhất, kiến thức được tổ chức thành 11 miền nghiệp vụ chính và 9 nguyên lý xuyên suốt.

11 miền nghiệp vụ#

3. Chín nguyên lý xuyên suốt phải thuộc lòng#

3.1 Một giao dịch — một sợi chỉ truy vết#

• Giao dịch xuyên module cần một Global ID / Glob_id.
• ID này phải xuất hiện hoặc ánh xạ được qua Channel log, business history, Slip, Voucher và GL.
• Khi xử lý incident, không bắt đầu bằng “bảng nào có dữ liệu”; hãy bắt đầu bằng ID nào nối được toàn bộ vòng đời.

3.2 Master là trạng thái, History là sự kiện#

• *_mas: trạng thái hiện tại, thường UPDATE.
• *_his / *_trx: lịch sử, thường INSERT append-only.
• Master tối ưu đọc trạng thái hiện tại; History phục vụ audit, movement, time series.
• Không dùng Master hiện tại để trả lời câu hỏi lịch sử nếu có thay đổi thuộc tính theo thời gian.

3.3 Grain trước, JOIN sau#

Trước khi JOIN, phải trả lời: mỗi dòng đại diện cho cái gì?

• Customer: 1 dòng/khách hàng.
• Account: 1 dòng/tài khoản.
• Execution: 1 dòng/khế ước.
• Transaction: 1 dòng/giao dịch.
• Snapshot: 1 dòng/thực thể/ngày.

Nếu JOIN bảng 1:N rồi SUM thuộc tính phía “1”, số liệu sẽ bị nhân bản. Hãy aggregate phía N về đúng grain trước.

3.4 Kế toán phải cân bằng#

• Slip mô tả chứng từ/sự kiện.
• Voucher mô tả bút toán Nợ/Có.
• Tổng DR phải bằng tổng CR.
• Inter-office/FTP toàn ngân hàng phải net về 0 theo quy tắc của hệ thống.

3.5 Batch phải idempotent#

Rerun cùng business_date + entity_key + process_type không được tạo thêm số liệu.

• Có khóa tự nhiên hoặc unique constraint chống trùng.
• Có trạng thái RUNNING/SUCCESS/FAILED.
• Có checkpoint và reconciliation trước khi publish.
• Không DELETE/INSERT mù nếu chưa khóa phạm vi dữ liệu.

3.6 Thời gian là một phần của khóa logic#

• MIS thường là T+1/T-1, không phải real-time.
• SCD/History phải JOIN theo valid_from <= trx_date < valid_to.
• Accrual phụ thuộc business date, holiday calendar, day count convention.
• Cut-off và timezone phải được đưa vào thiết kế, không để ngầm định.

3.7 Trạng thái là cổng kiểm soát#

Trước giao dịch cần kiểm tra tối thiểu:

• Customer/AML status.
• Account status: normal, dormant, blocked/accident, released.
• Limit/available balance.
• Product and channel eligibility.
• Approval/EDD nếu thuộc trường hợp bắt buộc.

3.8 Reconciliation là điều kiện hoàn tất#

Một luồng chưa hoàn thành chỉ vì job “SUCCESS”. Nó chỉ hoàn thành khi:

• Count khớp.
• Amount khớp.
• DR/CR khớp.
• Source/target khớp theo tolerance.
• Không có record mồ côi hoặc unmatched ngoài ngưỡng.

3.9 Dependency quan trọng hơn thời gian chạy#

Job đích không được chạy vì “đến giờ”; chỉ chạy khi các predecessor đã SUCCESS và reconciliation đạt yêu cầu. Đây là điểm sống còn của EOD, PMS và Risk.

PHẦN A — CUSTOMER & AML#

4. Customer/KYC/AML#

Mục đích#

Xác định đúng khách hàng, đo rủi ro, ngăn giao dịch bị cấm và tạo dữ liệu phục vụ CTR/STR.

Luồng nghiệp vụ nén#

Mermaid source (tùy chọn)

Khóa và dữ liệu trọng tâm#

• Khóa tích hợp khách hàng theo tài liệu: sh + lcl + corp_c + cusno.
• Dữ liệu tĩnh: danh tính, địa chỉ, nghề nghiệp, quốc tịch, ownership.
• Dữ liệu động: risk score, watchlist result, CDD/EDD status, alert/case.
• Customer Change Info phải kích hoạt đánh giá lại khi thuộc tính rủi ro thay đổi.

80/20 phải nhớ#

1. Watchlist phải diễn ra trước khi hoàn tất giao dịch có kiểm soát.
2. Risk score không phải dữ liệu “tính một lần”; phải tái đánh giá theo chu kỳ/chuyển biến.
3. Customer master và AML data phải cùng một integration key.
4. TMS tạo alert, con người/case workflow quyết định STR; alert không đồng nghĩa với vi phạm.
5. Giá trị chu kỳ 1Y/2Y/3Y, ngưỡng ownership 25% và nhóm bắt buộc EDD trong tài liệu là quy tắc nguồn, cần đối chiếu policy hiện hành trước Production.

Điểm rủi ro vận hành#

• False negative: bỏ sót người bị cấm do sai chính tả, transliteration hoặc dữ liệu thiếu.
• False positive: chặn nhầm do trùng tên, khiến case backlog tăng mạnh.
• Stale risk: change data đến chậm nên risk score không còn đúng.
• Broken identity: nhiều mã khách hàng cho cùng một người hoặc một mã map sang nhiều người.

Truy vết nhanh#

1. Kiểm tra customer integration key.
2. Kiểm tra dữ liệu nguồn và thời điểm cập nhật.
3. Kiểm tra phiên bản danh sách watchlist.
4. Kiểm tra score/rule version.
5. Kiểm tra approval/case status và audit log.

PHẦN B — CORE TRANSACTION, ACCOUNTING & EOD#

5. Vòng đời một giao dịch Core#

Luồng chuẩn#

Mermaid source (tùy chọn)

Ý nghĩa từng lớp#

• Business transaction: cập nhật tài khoản nghiệp vụ và history trong phạm vi ACID phù hợp.
• Slip: chứng từ gốc mô tả sự kiện giao dịch.
• Voucher: bút toán kế toán được sinh từ Slip.
• GL: số dư tổng hợp theo ngày, chi nhánh, COA, currency.

Các bảng được nhắc nhiều trong tài liệu#

• Slip: gdw_gac_slip_his, gac_slip_mas, gdc_slip_his.
• Voucher: gdw_gac_vouic_his.
• GL: gdw_gac_bspllc_mas, gdw_com_bsplic_inf, gac_bspllc_mas.
• Mapping COA: gdw_gac_acccdedic_mas.

Composite key quan trọng của GL#

standard_date + management_branch + COA + currency

Có thể còn chiều khác tùy thiết kế, nhưng bốn chiều này là trục aggregate cốt lõi trong tài liệu.

Incident kinh điển: App báo thành công nhưng GL thiếu#

Theo Glob_id, kiểm tra tuần tự:

1. Channel log có request/response không?
2. Master đã UPDATE chưa?
3. History đã INSERT chưa?
4. Slip đã sinh chưa?
5. Background process đã consume Slip chưa?
6. Voucher có đủ DR/CR không?
7. Local GL đã post chưa?
8. HQ GL đã nhận chưa?

Không sửa GL trực tiếp trước khi xác định đúng điểm gãy.

6. EOD: Accrual, FTP, Netting#

Luồng nén#

Mermaid source (tùy chọn)

Công thức/định luật cần nhớ#

• FTP theo tài liệu: average balance × FTP rate × day/365.
• Tiền tệ dùng NUMBER/DECIMAL, không dùng FLOAT.
• SUM phải xử lý NULL bằng NVL/COALESCE.
• Netting giúp giảm hàng triệu update xuống vài nghìn posting tổng hợp.
• Tổng Inter-office phải cân bằng theo invariant của hệ thống.

Rủi ro chính#

• EOD chạy cùng giao dịch realtime gây row lock/contention.
• Holiday/leap year/day-count sai làm sai accrual.
• Bảng history không partition khiến full scan kéo dài.
• Rerun không idempotent làm nhân đôi accrual/FTP.
• Job post GL chạy trước job tính detail hoàn tất.

Mẫu kiểm tra cân đối Oracle#

select business_date,
       sum(nvl(dr_amount, 0)) total_dr,
       sum(nvl(cr_amount, 0)) total_cr,
       sum(nvl(dr_amount, 0)) - sum(nvl(cr_amount, 0)) diff
from   daily_voucher
where  business_date = :p_business_date
group  by business_date
having abs(sum(nvl(dr_amount, 0)) - sum(nvl(cr_amount, 0))) > :p_tolerance;

PHẦN C — DEPOSIT#

7. Deposit Business & Data Model#

Vòng đời tài khoản#

1. Chọn sản phẩm: Demand / Time / Installment.
2. Mở tài khoản và sinh ID.
3. Giao dịch nộp/rút/chuyển.
4. Tính lãi dồn tích hàng ngày.
5. Settlement/renewal/maturity.
6. Thay đổi trạng thái: normal, dormant, accident/blocked, released.

Hai số tài khoản phải phân biệt#

• DEP_ACNO: surrogate key hệ thống, ổn định, dùng liên kết bảng.
• LCL_ACNO: số hiển thị cho khách hàng, có thể thay đổi/mapping.

Đây là thiết kế giúp đổi số hiển thị mà không cập nhật hàng triệu dòng history.

Cấu trúc bảng lõi#

• gdc_ac_mas: account master chung.
• gtd_td_mas: term deposit sub-master.
• gdd_lq_mas: demand/liquidity related master theo tài liệu.
• gdc_trx_his: transaction history.
• gdc_int_mas: interest master.
• gdc_intcal_his: interest calculation history.
• gdc_maschgdt_his: audit thay đổi master.
• gdc_rlytrx_his: linked transaction history.
• Nhóm gso_*: auto transfer/rollover/day-future transaction.

Công thức số dư trong tài liệu#

DEP AC BLC = PABL BLC + PMT RSTRT AMT

Hiểu theo nghiệp vụ:

• Ledger/account balance = available/payable balance + restricted/held amount.
• Khi cho phép rút tiền, ưu tiên kiểm tra available/payable balance, không chỉ ledger balance.

Quy tắc PK History#

DEP_ACNO + DEP_TRX_HIS_NO hoặc DEP_ACNO + *_SER_NO.

Serial phải duy nhất trong phạm vi tài khoản; sequence generation phải chịu được concurrency.

Rủi ro vận hành#

• Kênh mới quên kiểm tra dormant/blocked status.
• gdc_trx_his phình nhanh, không partition/pruning.
• Tài khoản thu hộ có hotspot row lock trên master balance.
• Accrual/renewal dùng sai rate version hoặc business date.
• Mid-term release tính sai lãi không kỳ hạn.

Truy vết lãi sai#

1. Xác định DEP_ACNO, product, term, status.
2. Kiểm tra rate history/effective date.
3. Kiểm tra daily balance và cut-off.
4. Kiểm tra gdc_intcal_his từng ngày.
5. Kiểm tra settlement/rollover job và rerun.
6. Đối chiếu GL interest posting.

PHẦN D — LOAN & COLLATERAL#

8. Loan lifecycle#

Cây tín dụng ba cấp#

Mermaid source (tùy chọn)

Chuỗi khóa quan trọng:

brw_aplct_no → lon_imt_no → lon_acno → exe_no

Một hạn mức có nhiều tài khoản; một tài khoản có nhiều lần giải ngân; một lần giải ngân có nhiều kỳ trả nợ.

Luồng nghiệp vụ#

1. Consultation/Application.
2. Credit appraisal & approval.
3. Create credit line.
4. Create loan account.
5. Disbursement/Execution.
6. Generate schedule.
7. Daily accrual and repayment.
8. Past-due/Early warning/Charge-off.

Bảng trọng tâm theo tài liệu#

• Application/approval: glm_cnsl_mas, glm_aplct_mas, glm_aprv_mas.
• Credit line/account: gle_lmt_mas, gle_acct_mas.
• Disbursement: gle_dsbs_mas, gle_dsbstrx_his.
• Schedule/overdue: gle_schd_mas, gle_schdpst_his.
• Appraisal/collateral: gla_aprs_mas, gla_estt_mas, gla_estbllon_inf, gla_coltr_inf.

Repayment patterns#

• Maturity/bullet: gốc cuối kỳ.
• Fixed principal: gốc đều, lãi giảm.
• Annuity: tổng gốc+lãi tương đối cố định.

Schedule là nguồn sự thật để xác định due/past due; không suy luận nợ quá hạn chỉ từ current balance.

9. Collateral architecture#

Tài sản bảo đảm nên là module tách biệt vì:

• Một collateral có thể bảo đảm nhiều facility/execution.
• Một loan có thể dùng nhiều collateral.
• Từng loại tài sản có thuộc tính riêng: real estate, vehicle, deposit, securities.
• Cần appraisal version, haircut, eligible value và allocation ratio.

Kiểm soát quan trọng#

• Tổng allocated collateral value không vượt eligible value.
• Không dùng appraisal hết hạn.
• Release collateral chỉ khi nghĩa vụ liên quan đã được giải phóng.
• Collateral-to-loan link phải có hiệu lực theo thời gian.

Incident nợ quá hạn không xuất hiện#

1. Kiểm tra gle_schd_mas có due item chưa.
2. Kiểm tra repayment/autodebit thực tế.
3. Kiểm tra business date/holiday treatment.
4. Kiểm tra job tạo gle_schdpst_his.
5. Kiểm tra account/execution status.
6. Kiểm tra ETL sang CIC/Risk có lấy đúng base date không.

PHẦN E — FX, REMITTANCE & TRADE FINANCE#

10. FX & Remittance#

Luồng Outward#

Applicant → Remitting Bank → Settle/Correspondent Bank → Paying Bank → Beneficiary.

Luồng điện#

Core → message generation → sanctions/watchlist → approval nếu caught → BIC/routing validation → SWIFT Alliance → receiving bank.

Điểm nhớ#

• Buying/Selling luôn nhìn từ góc độ ngân hàng.
• Settle Bank/Nostro là cầu thanh toán khi hai ngân hàng không có quan hệ trực tiếp.
• BIC/SWIFT code là routing key.
• MT103 thường gắn customer transfer; MT202 thường gắn bank-to-bank settlement theo ngữ cảnh nguồn.
• Mỗi message cần unique reference và idempotency để retry không gửi hai lần.

Bảng được nhắc#

• Outgoing remittance: gre_outgoing_mas.
• Incoming message/remittance: gsm_incoming_mas.
• Nhóm gre_mas, gre_amd, gre_stmt_inf phục vụ remittance/trade message theo tài liệu.

Rủi ro#

• Safe Watch/AML false positive làm điện stuck.
• Tỷ giá stale gây arbitrage/loss.
• Sai BIC/account làm tiền treo.
• Timeout nhưng message đã gửi gây duplicate transfer khi retry.

11. Trade Finance#

Vòng đời L/C nén#

Application → Issuance → SWIFT MT7xx → Amendment → Shipment/Documents → Document checking → Acceptance/Payment → Closure.

Phương thức thanh toán#

• T/T: chuyển tiền điện.
• D/P: documents against payment.
• D/A: documents against acceptance.
• L/C: ngân hàng cam kết thanh toán theo điều kiện chứng từ.

Kiểm soát dữ liệu#

• Version hóa amendment; không overwrite điều khoản cũ.
• Liên kết message reference với L/C reference và transaction reference.
• Theo dõi outstanding amount, utilization, commission và contingent liability.
• Sanctions screening phải áp dụng cho parties, banks, vessels/ports/goods khi policy yêu cầu.

PHẦN F — TREASURY & RECONCILIATION#

12. Treasury#

Phạm vi#

• Money Market.
• FX spot/forward/swap.
• Securities.
• Derivatives.
• Position, settlement, valuation, accounting.

Luồng deal#

Trade capture → confirmation → settlement instruction → cash/securities settlement → position update → valuation/M2M → accounting → reconciliation.

Rủi ro cốt lõi#

• Market price/feed sai làm P&L/M2M sai.
• Deal amendment không version hóa.
• Settlement date/currency mismatch.
• Position không khớp giữa front office, back office và GL.

13. Nostro/Vostro Reconciliation#

Hai tập dữ liệu#

• Shadow/Expected: hệ thống dự kiến ngân hàng đại lý sẽ ghi nhận.
• Actual: sao kê/thông tin thực tế từ ngân hàng đại lý.

Luồng matching#

Mermaid source (tùy chọn)

Matching key thường dùng#

Value date, currency, amount, reference, counterparty, direction. Không nên match chỉ bằng amount.

Bảng trọng tâm theo tài liệu#

• grc_shdw: shadow.
• grc_actl: actual.
• gsc_pst_inf, gmm_pst_inf: position/posting information theo module nguồn.

KPI vận hành#

• Unmatched count/amount.
• Aging của exception.
• Duplicate statement line.
• Auto-match rate.
• Adjustment count sau cut-off.

PHẦN G — CHANNEL#

14. Channel Architecture#

Luồng tổng quát#

Client/ATM/POS/API → Gateway/Switch → Channel service → Core/Tmax → External network nếu có → response → UMS notification.

Miền dữ liệu#

• ATM/POS transaction log.
• Domestic transfer/Clearing/RTGS.
• CMS/CFM/Bill payment.
• UMS SMS/email/push queue.
• Open API authentication, request/response, callback.

Bảng/khóa được nhắc#

• ATM logs: gat_trx_log, gat_obktrx_log.
• UMS: gms_dspch_mas, gms_umscust_mas, gms_dispch_tgt.
• Batch/file: gso_batfile_mas.
• Bill payment/CFM: gif_billpmnt_trx_log, nhóm gif_cfm_*.
• ATM trace key: atm_trx_trace_no.

Ba trạng thái timeout phải phân biệt#

1. Request chưa đến Core.
2. Core xử lý fail/rollback.
3. Core commit thành công nhưng response mất trên đường về.

Trường hợp 3 là nguyên nhân điển hình của duplicate retry. Vì vậy mỗi request phải có idempotency key và cơ chế query status.

Notification không phải giao dịch#

SMS/email fail không đồng nghĩa giao dịch fail. UMS là luồng bất đồng bộ; cần tách transaction status và notification status.

PHẦN H — MIS / DATA WAREHOUSE#

15. Kiến trúc nhiều tầng#

Mermaid source (tùy chọn)

Ý nghĩa#

• 0th: raw/basic snapshot từ Core/Channel.
• 1st: chuẩn hóa, tích hợp customer/account/product.
• 2nd: fact/dimension, history, mart nghiệp vụ.
• 3rd: KPI, profitability, risk aggregates.
• 4th: dashboard/file/report.

T+1 và đối soát#

Tài liệu nhấn mạnh “previous day”. Vì vậy:

• Không dùng MIS để xác nhận giao dịch real-time.
• Chỉ publish mart sau khi Core EOD hoàn tất.
• Mỗi tầng cần count/amount reconciliation.

Master/Slave và SCD#

• Master/current dimension không đủ cho báo cáo lịch sử.
• Với SCD Type 2, JOIN theo ngày hiệu lực:

select t.trx_id,
       t.trx_date,
       c.branch_code
from   fact_transaction t
join   dim_customer_scd c
  on   c.customer_no = t.customer_no
 and   t.trx_date >= c.valid_from
 and   t.trx_date <  nvl(c.valid_to, date '9999-12-31');

Cạm bẫy fan-out#

Sai:

select c.customer_no, sum(c.reported_asset)
from customer c
join deposit_account a on a.customer_no = c.customer_no
group by c.customer_no;

Đúng: aggregate phía account về customer trước khi JOIN.

with a as (
    select customer_no, sum(balance) total_balance
    from deposit_account
    group by customer_no
)
select c.customer_no, c.reported_asset, a.total_balance
from customer c
left join a on a.customer_no = c.customer_no;

Bảng/prefix được nhắc#

• gdw_com_cus_inf, gdw_com_acct_inf.
• gdw_com_cusdep_d, gdw_com_acpl_d.
• gdw_rsk_*: risk mart.
• pms_*: profitability mart.

Rủi ro#

• ETL chạy trước source cut-off.
• Join sai grain làm phồng số tiền.
• SCD join thiếu thời gian.
• Query report chọc thẳng OLTP.
• Late arriving data không có cơ chế restatement.

PHẦN I — PMS / PROFITABILITY#

16. Công thức lợi nhuận quản trị#

Theo tài liệu:

Net Profit
= Interest Income
+ Non-interest Income
+ FTP Revenue
- Interest Expense
- FTP Cost
- Cost of Work / ABC Cost
- Credit Cost

Luồng dữ liệu#

GL/transaction → COA mapping → interest/non-interest income → FTP → ABC allocation → credit cost → customer/account profitability → roll-up branch/product/group.

Các lớp bảng#

• Mapping/common: CMN_*, valuation/COA mapping.
• Account/customer profit: pms_pl_evalt_mas, pms_pl_cus_mas.
• ABC driver: PMS_ABC_DRV_*.
• Profitability analysis: PMS_PL_PA_*, bpms_pl_pa_cus_mas.
• Adjustment: PMS_ADJ_*, đặc biệt pms_adj_trns.
• Time series: pms_pl_evalt_ser_mon.

ABC Costing#

Chi phí → Activity → Driver quantity/ratio → Account/Customer/Branch.

Ví dụ driver: số giao dịch, thời gian xử lý, số tài khoản, số lần in sao kê. Khi denominator = 0, chi phí phải vào bucket “unallocated”, không được divide-by-zero hoặc biến mất.

Invariant bắt buộc#

Tổng profit phân bổ tại các dimension phải reconcile với GL/P&L sau các adjustment hợp lệ và tolerance làm tròn.

Rủi ro#

• COA mới chưa mapping làm doanh thu “rơi khỏi” PMS.
• Job tổng hợp chạy khi ABC/Credit Cost chưa xong làm profit ảo cao.
• Driver sai làm phân bổ chi phí méo.
• Adjustment overwrite system result thay vì lưu riêng.
• Profit sharing ratio không bằng 100% gây double counting.

Thiết kế adjustment an toàn#

Không update trực tiếp kết quả hệ thống. Lưu adjustment riêng:

select p.entity_id,
       p.system_profit,
       nvl(a.adjusted_amount, 0) adjusted_amount,
       p.system_profit + nvl(a.adjusted_amount, 0) final_profit
from   pms_profit p
left join (
    select entity_id, sum(adjusted_amount) adjusted_amount
    from pms_adjustment
    where approval_status = 'APPROVED'
    group by entity_id
) a on a.entity_id = p.entity_id;

PHẦN J — RISK MANAGEMENT#

17. Risk Basics#

Bộ ba tín dụng#

• PD: Probability of Default.
• LGD: Loss Given Default.
• EAD: Exposure at Default.

Công thức ghi nhớ:

Expected Loss = PD × LGD × EAD

RWA/BIS#

RWA biến exposure thành tài sản có trọng số rủi ro. Capital adequacy/BIS ratio so sánh vốn đủ điều kiện với RWA theo framework áp dụng.

ALM/Liquidity#

• Time bucket dòng tiền.
• LCR: khả năng chịu stress thanh khoản ngắn hạn.
• NSFR: nguồn vốn ổn định dài hạn.
• Phải đồng bộ maturity, repricing date, currency và behavioral assumptions.

Luồng dữ liệu Risk#

Core Loan/Deposit/Trade/Treasury → EAD base → collateral/guarantee → customer/group aggregation → engines TE/RWA/ALM/Market Risk → risk mart/report.

Bảng được nhắc#

• gdw_rsk_ead_mas, gdw_rsk_ead_sum_mas.
• gdw_rsk_cus_inf, gdw_rsk_csum_mas.
• gdw_rsk_ibs_dmb_link.
• gdw_rsk_alm_est_mas.
• gdw_rsk_tot_coa_inf.

Rủi ro dữ liệu#

• Chỉ lấy on-balance, bỏ off-balance commitment/guarantee.
• Collateral mapping thiếu hoặc double allocation.
• PD/LGD model version không khớp base date.
• ALM time bucket sai do maturity/repricing date.
• Currency conversion dùng rate không cùng cut-off.

Checklist khi EAD/RWA bất thường#

1. Base date và population.
2. On/off balance completeness.
3. CCF/guarantee/collateral logic.
4. Customer/group mapping.
5. Model/risk weight version.
6. FX rate.
7. Aggregation grain và reconciliation về source.

PHẦN K — INFRASTRUCTURE#

18. Core Banking Infrastructure#

Mô hình#

Mermaid source (tùy chọn)

Vai trò#

• DMZ giảm blast radius khi web bị compromise.
• L4 phân phối tải/failover AP.
• AP Active-Active chia tải.
• Tmax/TP monitor quản lý transaction, session, connection pool.
• RAC cung cấp multi-instance HA trên shared database.
• DR bảo vệ trước site disaster; DR không thay thế backup.

Rủi ro#

• RAC split-brain/interconnect latency.
• Service placement sai, hot instance.
• L4 health check chỉ kiểm tra port, không kiểm tra business readiness.
• Connection pool cạn do DB chậm/lock/leak.
• DR lag hoặc failover runbook chưa được test.

Quan sát theo lớp#

1. Network: latency, packet loss, firewall.
2. L4: active connections, health checks, distribution.
3. AP/Tmax: queue, thread/process, pool usage, error rate.
4. DB: sessions, blocking, wait events, CPU/I/O, ASM/storage.
5. Batch: scheduler, dependency, elapsed time.
6. DR: transport/apply lag, recoverability.

PHẦN L — PLAYBOOK XỬ LÝ SỰ CỐ#

19. Ma trận triệu chứng → đường kiểm tra#

20. Bộ câu hỏi phải hỏi trước khi sửa dữ liệu#

1. Business date nào?
2. Grain của record là gì?
3. ID truy vết xuyên luồng là gì?
4. Source of truth nằm ở bảng nào?
5. Dữ liệu là trạng thái hiện tại hay history?
6. Có job bất đồng bộ nào chưa hoàn tất không?
7. Có thể rerun an toàn không?
8. Reconciliation invariant là gì?
9. Sửa một dòng sẽ ảnh hưởng bảng downstream nào?
10. Rollback và audit evidence là gì?

PHẦN M — MẪU SQL AN TOÀN CHO ORACLE#

21. Kiểm tra duplicate theo natural key#

select business_date, entity_id, process_type, count(*) cnt
from   target_table
where  business_date = :p_business_date
group  by business_date, entity_id, process_type
having count(*) > 1;

22. MERGE idempotent#

merge into target_table t
using (
    select :p_business_date business_date,
           s.entity_id,
           s.amount
    from   source_table s
    where  s.business_date = :p_business_date
) s
on (    t.business_date = s.business_date
    and t.entity_id     = s.entity_id )
when matched then update
    set t.amount        = s.amount,
        t.updated_at    = systimestamp
when not matched then insert
    (business_date, entity_id, amount, created_at)
values
    (s.business_date, s.entity_id, s.amount, systimestamp);

23. Pre-aggregate trước JOIN#

with trx as (
    select account_no,
           sum(amount) total_amount
    from   transaction_history
    where  trx_date >= :p_from_date
    and    trx_date <  :p_to_date + 1
    group  by account_no
)
select a.account_no,
       a.current_balance,
       nvl(t.total_amount, 0) total_amount
from   account_master a
left join trx t on t.account_no = a.account_no;

24. Detect orphan record#

select h.*
from   account_history h
where  not exists (
    select 1
    from account_master m
    where m.account_no = h.account_no
);

25. Reconciliation source/target#

with src as (
    select count(*) cnt, sum(nvl(amount,0)) amt
    from source_table
    where business_date = :p_business_date
), tgt as (
    select count(*) cnt, sum(nvl(amount,0)) amt
    from target_table
    where business_date = :p_business_date
)
select src.cnt src_cnt,
       tgt.cnt tgt_cnt,
       src.amt src_amt,
       tgt.amt tgt_amt,
       src.cnt - tgt.cnt cnt_diff,
       src.amt - tgt.amt amt_diff
from src cross join tgt;

PHẦN N — CÁCH HỌC VÀ HỒI KIẾN THỨC#

26. Thứ tự học tối ưu#

1. Transaction → Master/History → Slip/Voucher/GL.
2. Deposit và Loan key chain.
3. EOD/Accrual/FTP/Netting.
4. Channel và International Payment.
5. DW/MIS: grain, SCD, anti-duplication.
6. PMS và Risk.
7. Infrastructure và incident tracing.

27. Phương pháp 5 phút#

Mỗi module tự trả lời năm câu:

1. Input là gì?
2. ID/PK xuyên suốt là gì?
3. Bảng Master và History nào?
4. Job bất đồng bộ/EOD nào?
5. Invariant/reconciliation nào chứng minh kết quả đúng?

28. Móc trí nhớ#

• AML: “Biết người → lọc người → chấm người → giám sát giao dịch”.
• Accounting: “Sự kiện thành Slip, kế toán thành Voucher, số dư vào GL”.
• Deposit: “DEP_ACNO là gốc; số hiển thị chỉ là mặt tiền”.
• Loan: “Line che Account, Account chứa Execution, Execution sinh Schedule”.
• Channel: “Timeout không nói được commit hay chưa”.
• DW: “Gom N trước khi gặp 1; JOIN lịch sử phải kèm ngày”.
• PMS: “Thu nhập + FTP − chi phí − rủi ro”.
• Risk: “PD × LGD × EAD; đừng quên ngoại bảng”.
• Infra: “Theo dõi từ L4 → AP/Pool → DB Wait → Storage”.

29. Ranh giới giữa dữ kiện và suy luận#

Khi trả lời câu hỏi dựa trên bộ ROM này, nên phân loại:

• [SOURCE]: nội dung được nêu trực tiếp trong file.
• [INFERENCE]: suy luận kiến trúc/kỹ thuật hợp lý từ nội dung.
• [VERIFY]: thông tin cần đối chiếu policy, data dictionary, source code hoặc Production log.

Điều này đặc biệt quan trọng với threshold AML, cut-off, tên bảng, status code, công thức lãi và quy định pháp lý.