admission-rules-scan

L3 Access Rule Scan

Based on the customer profile and the risk control rule base of the target credit product, determine whether the customer meets the access conditions and output a structured scan report.

Execution Workflow

Interaction Mode: Mode A - Report Generation

When the user requests an assessment of a customer's product access conditions, execute according to the following workflow:

Step 0: Data Confirmation and Verification (Read Before Write)

Confirm customer identity: extract customer name or ID
Confirm target product: extract product name or code
Check required fields: customer name, target product, requested credit amount (recommended)
Run validation script: python scripts/validate_admission_scan.py --check-customer --check-product
If required fields are missing, output a missing-items list, ask the user to supplement them, and stop the subsequent workflow
After validation passes, proceed to Step 1

📋 Data source:user_upload 📋 Executing entity:ai 📋 Confirmation mechanism:none ⚠️ Mandatory instruction: Do not skip the required field check; customer and product information must be confirmed as complete

Step 1: Load Customer Profile

Integrate multi-dimensional customer information to form a complete foundational data set for access assessment. Integration tip: Map to your bank's Enterprise Customer Information File (ECIF), credit inquiry interface, customer 360 view, or equivalent data aggregation tools

Basic Information Dimensions

Corporate registration: industry, years in operation, registered capital (subscribed/paid-in), legal representative/actual controller
Operating scale: annual operating revenue, number of employees, total assets, main business regions
Financial condition: debt-to-asset ratio, current ratio, quick ratio, net profit trend over the past 2 years

Credit Record Dimensions

Credit report: outstanding loans, overdue records (past 2 years), external guarantee balance, frequency of credit inquiries
In-bank records: historical credit usage, repayment performance, whether there are special-mention/non-performing records

Related Information Dimensions

Guarantee relationships: total external guarantees, credit status of guaranteed parties, whether there are mutual guarantees/group guarantees
Related-party risk: litigation/credit default/abnormal operations of other enterprises under the actual controller's name

Profile Completeness Self-Check

If key fields are missing (such as revenue data or credit report), record the missing items and mark the source as "To Be Confirmed"; do not skip or fabricate

📋 Data source:system_api(ECIF system, credit interface, business registration data) 📋 Executing entity:ai 📋 Confirmation mechanism:none

Step 2: Load Product Access Rules

Obtain all risk control rules bound to the target product and sort them by priority. Integration tip: Map to your bank's product rule base/risk control engine rule interface, or equivalent rule management tools

Rule Priority

Fixed items (P0): Basic access conditions that must be checked for all customers, such as years in operation ≥ X years, no current overdue on credit report
Industry items (P1): Industry-specific access restrictions, such as additional requirements for real estate and industries with "two highs and one surplus"
Specific item (P2): Supplementary rules for individual cases, such as additional requirements for large credit lines and related-party transaction restrictions

Rule Classification | Rule Category | Typical Examples | Data Source | |---------|---------|---------|| | Entity Qualification | Years of establishment, paid-in registered capital ratio, frequency of legal representative changes | Business registration data | | Industry Access | Determination of encouraged/restricted/eliminated industries | Industrial policy + in-bank whitelist | | Financial Thresholds | Upper limit of debt-to-asset ratio, lower limit of revenue, net profit requirements | Financial statements/credit reporting | | Credit Record | No current overdue, upper limit on number of overdue occurrences in the past 2 years | Credit report | | Concentration | Single-customer credit concentration, group credit concentration | In-bank credit system | | Compliance Requirements | Environmental compliance, safety production license, franchise qualification | External regulatory data |

📋 Data Source:system_api(Credit system product management measures, risk control engine rules) 📋 Executing Entity:ai 📋 Confirmation Mechanism:none

Step 3: One-Vote Veto Pre-Scan (Gating Step)

Gating step: If any A1-A6 condition is triggered at this step, subsequent rule matching is immediately terminated, and "Access Not Passed" is output directly

One-Vote Veto Conditions (A1-A6)

| No. | Trigger Condition | |------|---------|| | A1 | The enterprise or actual controller currently has unsettled overdue payments (credit report M2 or above) | | A2 | The enterprise belongs to an industry explicitly eliminated by regulators and has no proof of compliant transformation | | A3 | The enterprise has been listed as a dishonest judgment debtor, or the actual controller is subject to a high-consumption restriction | | A4 | There are records of serious dishonest conduct such as loan fraud, capital withdrawal, or false statements in the past 2 years | | A5 | Total external guarantees > 100% of net assets, or there is a risky mutual guarantee/joint guarantee circle | | A6 | The enterprise or actual controller is involved in compliance blacklists such as money laundering or terrorist financing |

Gating Path:

❌ Trigger any A1-A6 → Stop Immediately, output "Access Not Passed" + trigger condition + proceed to Step 4 (generate scan report)
✅ No one-vote veto triggered → proceed to Step 4 (rule-by-rule matching)

📋 Data Source:system_api(Credit report, judicial data, compliance blacklist) 📋 Executing Entity:ai 📋 Confirmation Mechanism:none ⚠️ Mandatory Instruction: This step must be executed; the one-vote veto check must not be skipped, and it must not be ignored because "the customer's qualifications are good"

Step 4: Rule-by-Rule Matching

Perform a three-state judgment for each rule, strictly comparing against thresholds

Definition of Matching Results | Result | Judgment Standard | Output Requirement | |------|---------|---------|| | ✅ Pass | Customer conditions fully satisfy the rule threshold | List the rule name and matching value | | ❌ Not Satisfied | Customer conditions do not satisfy the rule threshold | List the rule name, threshold requirement, actual value, and gap | | ⏸️ Needs Confirmation | Key information is missing and cannot be judged | List the missing fields and suggested supplementary materials |

Key Points for Matching Execution

Each rule must record: rule name, rule category (P0/P1/P2), threshold requirement, customer's actual value, matching result, and gap (if any)
Financial rules use the most recent audited financial statement data; if unavailable, mark the "unaudited" risk
Industry classification is based on the national standard GB/T 4754 and cross-checked against the in-bank whitelist

📋 Data Source:context(Customer profile, product rules) 📋 Executing Entity:ai 📋 Confirmation Mechanism:none ⚠️ Mandatory instruction: no ambiguous judgments allowed; all numerical rules must be accurate to two decimal places; the calculation process must be shown.

Step 5: Generate scan report

Aggregate matching results and output a structured assessment report.

After executing Step 4, proceed to Step 5 and generate the complete report according to the requirements in the Output Format section.

📋 Data source:context(matching results) 📋 Executing entity:ai 📋 Confirmation mechanism:none

Output Format

This output can be parsed and used by the credit-due-diligence Skill.

Use the assets/admission-scan-template.md template. The scan report must include the following 6 sections:

Section	Content	Downstream parseable fields
1. Overall assessment	Admission conclusion, quick overview of key indicators	`admission_result`(enum)、`key_indicators`(array)
2. Compliant items	List of rules passed	`passed_rules`(array)、`passed_count`(int)
3. Non-compliant items	List of rules not met + gap analysis	`failed_rules`(array)、`failed_count`(int)、`gaps`(array)
4. Items requiring confirmation	Missing fields and list of supplementary materials	`pending_rules`(array)、`missing_fields`(array)
5. Risk alerts	Policy/concentration/trend risks	`risk_warnings`(array)
6. Improvement suggestions	Short-term/medium-term/structural suggestions	`improvement_suggestions`(array)

Disclaimer requirements: The end of the report must include the following statement (referencing the shared/disclaimer-template.md template):

---
> ⚠️ 免责声明:本扫描结果仅供授信方案设计参考,不构成最终审批意见。实际审批结果以信贷审批委员会决议为准。
> 数据来源:[列出数据源及时间戳] | 规则库版本:[版本号] | 扫描时间:[YYYY-MM-DD HH:MM]

Core Constraints

Regulatory basis

Measures for the Administration of Loan Business of Commercial Banks (CBRC Order No. 2 of 2010) — Loan objects and conditions
Guidelines for the Regulatory Internal Rating System for Credit Risk of Commercial Banks — Customer rating and admission standards
Measures for the Administration of Large Exposure of Commercial Banks (CBIRC Order No. 1 of 2018) — Concentration control
Bank internal credit policies and product management measures — Source of specific admission rules

Hard execution constraints

Rule priority order: Fixed items (required for all customers) > industry items (industry-specific) > targeted items (case-specific supplements), executed in order.
Veto items upfront: Scan the A1-A6 veto conditions first; if triggered, terminate subsequent rule matching immediately and directly output "Admission not passed."
Strict threshold comparison: Quantitative thresholds in the rules (such as minimum revenue and maximum debt ratio) must be compared precisely; ambiguous judgments are not allowed.
Insufficient information must be marked "requires confirmation": When data is missing, it must not be inferred as "passed" or "not met"; it must be clearly marked and supplementary materials must be listed.
Gap quantification: Non-compliant items must provide specific gap values (e.g., "revenue required ≥ RMB 50 million, actual approximately RMB 32 million, gap RMB 18 million").
Skipping steps prohibited: Step 0 (data confirmation) and Step 3 (veto check) must not be skipped; the complete process must be executed.
Mandatory red-line enforcement: If any veto condition (A1-A6) is triggered, subsequent matching must stop immediately and must not be ignored because "the customer has good qualifications."

Audit Trail

Generate an audit log after each execution. audit/{customer_name}_{date}_admission_scan_audit.json:

{
  "skill_name": "admission-rules-scan",
  "skill_version": "2.0.0",
  "execution_time": "2026-05-05T17:00:00+08:00",
  "customer_name": "[客户名称]",
  "operator": "[客户经理姓名]",
  "steps": [
    {
      "step": "数据确认与验证",
      "executor": "ai",
      "data_source": {"type": "user_upload"},
      "result": "pass",
      "details": "必填字段完整,客户名称和产品名称已确认"
    },
    {
      "step": "一票否决前置扫描",
      "executor": "ai",
      "data_source": {"type": "system_api"},
      "result": "pass",
      "details": "A1-A6均未触发"
    },
    {
      "step": "逐条规则匹配",
      "executor": "ai",
      "data_source": {"type": "context"},
      "result": "pass",
      "details": "P0规则8条(通过6条,不满足1条,需确认1条),P1规则3条(通过3条),P2规则2条(通过2条)"
    }
  ],
  "admission_result": "准入通过",
  "triggered_veto": [],
  "compliance_check": {
    "all_rules_scanned": true,
    "threshold_exact_match": true,
    "gap_quantified": true
  },
  "log_retention_years": 3
}

Audit log retention period: At least 3 years.

Gotchas

#1: The veto check was skipped, causing formal approval to be rejected.

Symptoms: The admission scan showed "Pass," but a single veto was exercised during the formal credit approval.
Cause: The A1-A6 checks were not strictly executed during the scan, or expired credit data was used.
Solution: In Step 3, add the mandatory instruction "This step must be executed; the single-veto check must not be skipped," and record the triggered_veto field in the audit log.

#2: The gap analysis is not specific, so the account manager cannot formulate an improvement plan

Symptom: Nonconformities only show "Not Satisfied," without giving specific gap values.
Cause: The gap quantification requirement was not strictly executed.
Solution: In Article 4 of the quality requirements, add "The absolute value and relative proportion of the gap must be given."

#3: Items requiring confirmation are assumed to pass

Symptom: When key fields are missing, the model infers "Pass," resulting in inaccurate risk assessment.
Cause: The principle of marking "Requires Confirmation" when information is insufficient was not strictly executed.
Solution: In Step 1, add a profile completeness self-check; in Constraint Article 4, add "It must not be inferred as pass or not satisfied."

#4: The rule base version is not indicated, so scan results cannot be traced

Symptom: The same customer has inconsistent scan results at different times, but it cannot be determined whether this is due to rule changes or customer changes.
Cause: The rule base version number was not recorded.
Solution: The output format mandatorily requires marking the "Rule Base Version" and "Scan Time."

Examples

Example 1: Working capital loan admission scan for a standard manufacturing enterprise

User input:

客户:XX机械制造有限公司
产品:流动资金贷款
申请金额:5000万元
行业:C34 通用设备制造业

Skill execution process:

Step 0: Confirm the customer name, product name, and application amount
Step 1: Load the customer profile (ECIF system, credit report, financial statements)
Step 2: Load the working capital loan product rule base (P0/P1/P2)
Step 3: Execute the single-veto scan (A1-A6) → not triggered
Step 4: Match rule by rule → P0 (6/8 passed), P1 (3/3 passed), P2 (2/2 passed)
Step 5: Generate the scan report → Admission passed (2 items not satisfied, 1 item requiring confirmation)

Output points:

Overall assessment: Admission passed
Nonconformities: Debt-to-asset ratio exceeds the standard (required ≤70%, actual 75%, gap 5%)
Items requiring confirmation: Missing the latest audit report
Improvement suggestions: Supplement the audit report in the short term, and reduce the debt ratio in the medium term

Example 2: Admission scan for a customer in an eliminated industry (single veto triggered)