post-loan-management

Target Role

Role: Post-loan management position / risk reviewer
Usage Scenario: Continuous post-loan management after loan disbursement—initial inspection, routine inspection, risk early warning, classification adjustment
Output Purpose: Generate a structured post-loan inspection report as the basis for risk classification adjustment, early warning disposal, and regulatory inspection
Decision Level: Provide risk analysis and classification recommendations; classification downgrade to non-performing category requires manual approval
Execution Frequency: Determined by the customer risk classification and credit amount matrix (see references/check-frequency-policy.md)

Data Sources

Required Data

Data Item	Source	Acquisition Method	Sensitivity Level
Customer basic information	Credit system	API: /api/credit/customer	Internal
Credit ledger (limit/balance/term/guarantee)	Credit system	API: /api/credit/exposure	Internal
Financial statements (last 3 years + latest period)	User upload / Credit system	File upload or API	Internal
Credit report	PBOC credit report	API after manual authorization	Confidential
Fund flow details	Credit/Payment system	API: /api/payment/flow	Internal
Collateral value data	Collateral management system	API: /api/collateral/value	Internal
Industry benchmark data	references/industry-benchmarks.md	File reading	Public

Data Masking Rules

Enterprise Unified Social Credit Code: show first 6 and last 4, with * in between
Customer contact mobile number: show only first 3 and last 4
Bank account number: show only last 4 digits
Collateral detailed address: not fully displayed in output; show only region and type

Degradation Strategy

If credit report data is unavailable: mark "credit dimension not included", and continue the remaining analysis
If financial statements cover only 1 year: mark "insufficient data, trend analysis unavailable", and perform static analysis only
If fund flow details cannot be obtained: mark "fund flow verification cannot be executed, manual retrieval recommended", and continue the remaining inspections
If collateral value data is unavailable: mark "collateral value is based on the most recent valuation and may not reflect the current market price"
If external industry data is unavailable: use the benchmark data in references/ and mark "based on historical benchmark data"

Terminology

Easily Confused Terms	Meaning in This Skill
Days past due	Calculated from the day after the agreed repayment date, including any grace period (if applicable)
Liquidity	Current ratio / quick ratio (non-market liquidity)
Restructured loan	A loan for which concessions have been made to the original contract terms due to the borrower's financial difficulties
Cross-default	The customer defaults on debts owed to other financial institutions, triggering the default clauses under this contract
Upgrade to special mention	A classification upgrade must satisfy 3 consecutive months of improvement and no new risk signals
First inspection	The first post-loan inspection within 30 days after disbursement, completed on-site 100%

Execution Workflow

Read before write: Before starting any analysis, the following data confirmation steps must be performed:

Read and list all input data (customer information, credit ledger, financial statements, credit report, etc.)

Confirm the data time range, accounting standards (CAS/IFRS), and currency

Run scripts/validate_post_loan_data.py verify data completeness and cross-reconciliation relationships

Proceed to Step 1 only after verification passes

Step 1: Post-loan inspection planning and preparation

Determine inspection frequency and focus based on the customer's risk classification and credit amount, and prepare the inspection checklist.

Consult references/check-frequency-policy.md determine the inspection frequency matrix
Review the customer's recent files, historical post-loan inspection records, and early warning disposal records
Check the customer's latest credit report, judicial information, and public opinion trends
Mark unresolved items found in the previous period as key points for this inspection

✅ Inspection plan generation completed → proceed to Step 2
❌ Customer basic information missing → stop the inspection and output the missing list
⚠️ Some data unavailable → handle according to the data access degradation strategy, continue, and note in the report

📋 Data source:user_upload(inspection parameters provided by the customer)

Step 2: Verification of fund use and flow

Verify the flow of loan funds transaction by transaction against the prohibited list in references/fund-usage-policy.md .

Verify the flow of entrusted payment funds: check the payee and the authenticity of the transaction background against the contract terms
Spot-check large self-directed payment expenditures (single transaction > 1 million): verify whether the use complies with the contract terms
Perform fund回流 verification: identify abnormal transactions flowing back to the borrower/related parties within 7 days/30 days
For fixed asset loans, verify capital in place and its match with project progress
Against the prohibited flow list, mark疑似违规流向 transaction by transaction

Run scripts/check_fund_usage.py --input {fund_flow_data} --rules references/fund-usage-policy.md perform automated violation detection.

✅ No violations found → proceed to Step 3
❌ Misappropriation of funds found → mark as a one-vote veto condition (P1), output a red alert, proceed to Step 5 but highlight in red in the final report
⚠️ Some transaction backgrounds questionable → mark as a yellow alert, proceed to Step 3, and note in the report

📋 Data source:system_api(credit system fund flow data)

Step 3: Business condition and financial health inspection

Analyze the customer's operational stability and financial health.

Read the financial statements and verify the business condition according to the following dimensions:
- Revenue changes (year-on-year/month-on-month)
- Orders and production (order backlog, capacity utilization)
- Changes in major customers/suppliers
- Inventory and turnover
- Personnel changes
Calculate financial health indicators (current ratio, quick ratio, debt-to-asset ratio, interest coverage ratio, operating cash flow/total liabilities, days sales outstanding), consult references/industry-benchmarks.md to obtain industry benchmarks
Compare against references/financial-warning-thresholds.md to determine whether early warning is triggered
Perform financial fraud identification checks (cross-verification of statements with tax control/transaction records, revenue and cash flow matching, related-party transactions, period-end rushed collections)

Analysis requirements：

Do not skip any indicator, even if some indicators "appear normal"
All ratios must show the calculation process; conclusions must not be given directly
If an indicator does not match expectations, stop and analyze the cause

Run scripts/calculate_financial_ratios.py --input {financial_data} --benchmarks references/industry-benchmarks.md to calculate financial indicators and compare them with industry benchmarks.

✅ Operations normal, financial indicators within normal range → proceed to step 4
⚠️ Some indicators enter the watch range → mark early warning signals, proceed to step 4
❌ Multiple indicators enter the warning range or financial fraud is found → mark orange/red warning, proceed to step 4

📋 Data source:user_upload(user-uploaded financial statements)

Step 4: Collateral validity and external risk environment check

Verify the value of collateral and changes in the external environment.

Verify one by one according to collateral type (mortgage/pledge/guarantee):
- Changes in the market value and physical condition of the mortgaged property
- Creditworthiness of the obligor for the pledged property
- Financial and credit status of the guarantor
Consult references/collateral-policy.md to obtain the upper limits of loan-to-value ratios and early warning thresholds for various types of collateral
Assess changes in industry policy, regional risk, market risk, and the credit environment
Quantify the impact of changes in the external environment on the customer's repayment ability

✅ Collateral valid, no major adverse changes in the external environment → proceed to step 5
⚠️ Collateral value falls ≥ 15% but < 25% → mark yellow warning, proceed to step 5
❌ Collateral is seized or the guarantor's creditworthiness deteriorates severely → mark red warning, proceed to step 5

📋 Data source:system_api(collateral management system, guarantor credit report)

Step 5: Early warning identification and risk classification assessment

Based on the above verification results, identify early warning signals and assess risk classification.

Summarize all early warning signals identified in steps 2-4, compare against references/early-warning-indicators.md to determine the level (yellow/orange/red)
Consult references/five-classification-policy.md(five-category classification standards), assess whether the current classification is accurate
Make a comprehensive judgment based on the principle of "substance over form" (overdue days are for reference only)
If the classification needs to be adjusted, attach detailed analysis basis

Veto condition check: check item by item the P1-P6 veto conditions (see references/p1-p6-veto-conditions.md). Triggering any condition must immediately result in a red warning.

Run scripts/evaluate_risk_classification.py --input {assessment_data} --policy references/five-classification-policy.md to generate classification recommendations.

✅ Classification accurate, no new major risks → proceed to step 6
⚠️ Classification needs to be downgraded but not to non-performing → output downgrade recommendation and basis, proceed to step 6
❌ Classification needs to be downgraded to non-performing or a veto condition is triggered → output red warning and classification downgrade recommendation, proceed to step 6

📋 Executing Entity:ai→human(AI-generated classification recommendation → risk reviewer confirmation) 📋 Confirmation Mechanism:approve(downgrade of substandard classification requires manual approval)

Step 6: Early Warning Disposal and Post-Loan Report Generation

Formulate disposal plans for identified early warning signals and generate a structured post-loan inspection report.

Verify early warning signals (rule out false positives) and assess the severity of the risk
Formulate differentiated disposal plans according to early warning levels:
- Yellow warning: increase monitoring frequency and require the customer to supplement materials
- Orange warning: reduce exposure, add collateral, and adjust credit conditions
- Red warning: initiate early loan collection, litigation preservation, and transfer of non-performing loans
Refer to references/disposal-escalation-policy.md to determine the reporting path and time limit
Use assets/post-loan-report-template.md to generate the post-loan inspection report
Append a disclaimer at the end of the report (use assets/disclaimer-template.md）

Output the complete post-loan inspection report.

📋 Executing Entity:ai→human(AI-generated report → dual signature by inspector and person in charge for archiving) 📋 Confirmation Mechanism:approve(the report may only be archived after dual signature)

Output Format

Use the assets/post-loan-report-template.md template. The report must contain the following structured sections:

1. Basic Customer Information

Field	Type	Description
Enterprise Name	string	Full enterprise name
Unified Social Credit Code	string	After masking (first 6 and last 4)
Credit Line	number	Ten thousand yuan
Credit Balance	number	Ten thousand yuan
Credit Term	string	Start and end dates
Guarantee Method	enum	Credit/Guarantee/Mortgage/Pledge/Combination
Current Risk Classification	enum	Normal/Special Mention/Substandard/Doubtful/Loss

2. Overview of the Current Inspection

Field	Type	Description
Inspection Date	string	YYYY-MM-DD
Inspection Method	enum	On-site/Off-site/Undercover
Inspector	string	Name/Employee ID
Customer Cooperation	enum	Cooperative/Partially cooperative/Uncooperative

3. Fund Usage Verification Results

Field	Type	Description
Fund Usage Compliance	enum	Compliant/Partially non-compliant/Seriously violating
Number of Suspected Violations	number	Transactions
Fund Return Identification	enum	Not found/Suspected/Confirmed
Handling Measures	string	Specific disposal actions

4. Operations and Financial Assessment

Field	Type	Value Range
Operating Condition Evaluation	enum	Stable/Average/Deteriorating
Financial Health	enum	Healthy/Attention/Warning
Number of Key Indicator Deviations	array	[Indicator name: actual value/benchmark value]

5. Guarantee Effectiveness Evaluation

Field	Type	Description
Collateral value change	number	Change percentage
Guarantor creditworthiness	enum	Good/Watch/Deteriorating
Registration validity	enum	Valid/Partially invalid/Fully invalid

6. Early warning signal list

Field	Type	Description
Signal ID	string	Unique identifier
Signal category	enum	Financial/Behavioral/Collateral/Operational/External
Early warning level	enum	Yellow/Orange/Red
Trigger condition	string	Specific description

7. Risk classification recommendation

Field	Type	Description
Current classification	enum	Normal/Watch/Substandard/Doubtful/Loss
Recommended classification	enum	Normal/Watch/Substandard/Doubtful/Loss
Classification rationale	string	Detailed analysis basis

8. Disposal recommendations and next-period plan

Field	Type	Description
Disposal measures	array	[Measure, Responsible person, Time limit]
Next inspection date	string	YYYY-MM-DD
Next-period focus	array	[List of focus points]

9. Disclaimer

The end of the report must include a disclaimer, using the assets/disclaimer-template.md standard template.

This output can be parsed and used by the credit-risk-classification and early-warning-disposal Skills.

Compliance Red Lines (Constraints)

Prohibition of return commitments: Under no circumstances may deterministic expressions such as "expected recovery," "expected to improve," or "recovery rate estimated at X%" appear.
Prohibition of data guessing: Missing data must be requested from the user or handled according to the degradation strategy; industry averages are strictly prohibited as substitutes for real data (industry averages are only used for benchmarking comparison).
Data timeliness annotation: If cited industry benchmark data exceeds its marked validity period, the output must be annotated with "⚠️ Industry benchmark data may be outdated."
Prohibition of unauthorized approval: This Skill only generates classification recommendations and disposal plans, and must not replace manual approval or automatically execute classification adjustments.
Prohibition of concealing risks: Identified early warning signals must not be downplayed or omitted; all early warnings must be truthfully listed and graded.
Prohibition of bypassing on-site inspection: Customers classified as Watch or above must undergo on-site inspection; telephone or system verification must not be used as a substitute.
Prohibition of backfilling after the fact: Post-loan inspection reports must be generated and archived in real time; after-the-fact backfilling or tampering with historical records is prohibited.
One-vote veto and immediate reporting: If any condition P1-P6 is triggered, a red alert must be issued immediately and an emergency report initiated; delayed handling is not permitted.

Audit Trail

After each post-loan inspection is completed, generate an audit log audit/{企业简称}_{日期}_post_loan_audit.json：

{
  "skill_name": "post-loan-management",
  "skill_version": "1.0.0",
  "execution_time": "YYYY-MM-DDTHH:mm:ss+08:00",
  "customer_id": "[脱敏]",
  "check_type": "首次检查/常规检查/风险分类调整/预警处置",
  "model": "claude-opus-4-7",
  "operator": "[姓名]（工号：[工号]）",
  "steps": [
    {
      "step": "数据确认与验证",
      "executor": "ai",
      "data_source": {"type": "user_upload"},
      "result": "通过/不通过",
      "duration_seconds": 0
    },
    {
      "step": "资金用途核查",
      "executor": "ai",
      "data_source": {"type": "system_api", "system": "信贷系统"},
      "result": "通过/不通过/预警",
      "findings_count": 0
    },
    {
      "step": "经营与财务检查",
      "executor": "ai",
      "data_source": {"type": "user_upload"},
      "result": "pass/fail/warning"
    },
    {
      "step": "担保有效性检查",
      "executor": "ai",
      "data_source": {"type": "system_api", "system": "押品管理系统"},
      "result": "pass/fail/warning"
    },
    {
      "step": "预警识别与分类评估",
      "executor": "ai→human",
      "data_source": {"type": "context"},
      "ai_output": "建议分类：[分类]",
      "confirmation": {"type": "approve", "approved_by": "[姓名]", "role": "风险审查人员", "final_decision": "[分类]"}
    },
    {
      "step": "报告生成与归档",
      "executor": "ai→human",
      "confirmation": {"type": "approve", "signed_by": "[检查人] + [负责人]"}
    }
  ],
  "warnings": ["如有"],
  "veto_conditions_triggered": [],
  "references_used": ["references/check-frequency-policy.md", "references/industry-benchmarks.md", "..."]
}

Audit logs must be retained for ≥ 3 years.

Gotchas

#1: Mistaking overdue days as the sole basis for classification

Symptom: Classifying loans overdue by 90 days directly as substandard, ignoring the borrower's actual repayment capacity and the adequacy of collateral.
Cause: Over-reliance on the number of overdue days, without performing a comprehensive judgment of "substance over form".
Solution: Strictly follow execution process step 5 — the number of overdue days is only for reference; judgment must comprehensively consider repayment capacity, adequacy of collateral, and recoverability.

#2: Insufficient penetration of fund回流 leads to missed judgment

Symptom: Only the direct payee was verified; funds that returned to the borrower after multiple layers of transfers were not identified.
Cause: Fund flow verification stopped only at the first-level counterparty, and penetration analysis was not performed.
Solution: As required by execution process step 2, penetrate to the final payee, focusing on abnormal paths where cumulative return within 7 days/30 days exceeds 30% of the loan amount.

#3: Excessive guarantor guarantees are ignored

Symptom: The guarantor's total external guarantees already exceed 50% of net assets, but it is still assessed as "good".
Cause: Only the guarantor's own financial indicators were considered; its total external guarantees were not verified.
Solution: As required by execution process step 4, guarantor verification must include the external guarantees/net assets ratio; > 50% must trigger an alert.

#4: Outdated industry benchmark data leads to misjudgment

Symptom: Using outdated industry benchmark data, a normally operating customer was misjudged as a financial warning.
Cause: The data validity period marked in references/industry-benchmarks.md has expired but has not been updated.
Solution: Before execution, check the data validity period markings of all references/ files; expired data must be marked "may be outdated" or rejected for use.

Examples

Example 1: Routine post-loan inspection of a normal-class customer

User input：

Please perform this quarter's post-loan inspection on XX Technology Co., Ltd. Current classification: normal class, credit amount 80 million yuan, guarantee method: real estate mortgage.

Skill execution process：

Data confirmation: read customer file, credit ledger, latest financial statements → verify data completeness → passed
Inspection plan: consult check-frequency-policy.md → normal class ≥ 50 million → once a month on-site + system inspection
Fund use verification: verify entrusted payment vouchers and large discretionary payments → no violations found → passed
Business and financial inspection: calculate financial indicators → current ratio 1.8, debt-to-asset ratio 52%, interest coverage ratio 4.2 → all within normal ranges → passed
Guarantee inspection: the value of the mortgaged real estate is stable, and the other rights certificate is valid → passed
Early warning identification: no new early warning signals → maintain normal-class classification
Generate post-loan inspection report (including disclaimer) → dual-signature archiving

Output summary: The customer operates normally, financial indicators are healthy, guarantees are valid, and there are no early warning signals. It is recommended to maintain the normal-class classification; next inspection date: [next month's date].

Example 2: A special-mention-class customer triggers an orange alert