> ## Documentation Index
> Fetch the complete documentation index at: https://docs.profiledrisk.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Lending & Credit Risk

Lending events represent requests to issue credit or increase exposure to existing users. These decisions carry financial risk because default, synthetic identity abuse, and loan stacking can occur if behavior is not thoroughly evaluated.

ProfiledRisk provides real-time lending risk intelligence by combining:

* **Your custom lending rules** tailored to product risk appetite
* **ProfiledRisk intelligence** assessing historical activity, device consistency, and identity stability

Each lending event returns a decision via the status field:

* **allowed** — continue loan approval workflow
* **blocked** — reject request
* **pending** — hold for additional checks or analyst decision

This ensures loans are issued only when risk signals align with expected borrower behavior.

## **When to Use This Use Case**

Use the **Lending** category when:

* A user submits a loan application
* Borrower profile or credit eligibility is updated
* A new loan request is made for an existing borrower
* Exposure changes require re-evaluation (credit limit increase, top-up)

Common triggers include:

* Salary advance applications
* Personal or SME loan requests
* Buy-Now-Pay-Later (BNPL) onboarding and repayment approvals
* Rapid repeat borrowing behavior

If the event increases business exposure, ProfiledRisk should evaluate it as a lending risk event.

## **Expected Event Inputs**

A Lending event should clearly describe the loan request, the borrower profile, and the context in which the request occurs.

### **Required signal groups:**

|                        |                                               |                                                            |
| ---------------------- | --------------------------------------------- | ---------------------------------------------------------- |
| **Category**           | **Example Fields**                            | **Risk Purpose**                                           |
| **Loan request**       | amount, purpose, loan\_term, interest\_rate   | Detect high-risk product misuse and affordability issues   |
| **User profile**       | employment status, income, tier, KYC          | Validate credibility and repayment capacity                |
| **Behavioral context** | registration\_time, recent credential changes | Prevent fraudulent credit access and ATO abuses            |
| **Device & network**   | device\_id, OS, IP                            | Identify identity sharing, collusion, and takeover risk    |
| **Address & location** | declared addresses and geography              | Support jurisdiction checks and fraud clustering detection |

Full schema is documented in [here](/docs/payload-schemas/lending-events)

Example snippet from your payload:

```
"loan": {
  "id": "87554303-3f75-4883-8fb8-48fce003859f",
  "time": "2022-12-12T12:15:05.391Z",
  "amount": 10000,
  "channel": "mobile",
  "purpose": "Salary Advance",
  "interest_rate": 18.5,
  "loan_product": "personal",
  "loan_term": 24

}
```

Full Schema definitions are located under **API Integration → Lending Events**.

ProfiledRisk uses onboarding and payment history to contextualize the credit request.

## **Decisioning Logic**

Evaluation combines:

### **1. Your Rules**

Configured in Flows, such as:

* Employment and income validation requirements
* Minimum credit score thresholds
* Rules preventing excessive exposure per borrower
* Enhanced verification for first-time lending customers

### **2. ProfiledRisk Intelligence**

Including:

* Loan stacking detection across shared devices or profiles
* Spike in risk signals preceding requests
* Weak identity correlated with high credit appetite
* Cross-entity behavioral anomalies (e.g., same device, different users)

### **Response Example**

```
{
  "status": "pending",
  "risk_score": 78,
  "risk_level": "high",
  "case_created": true
}
```

### **Client Enforcement Behavior**

|            |                                                         |
| ---------- | ------------------------------------------------------- |
| **Status** | **Action Required in Lending Workflow**                 |
| allowed    | Continue credit assessment or disbursement              |
| blocked    | Reject loan request                                     |
| pending    | Require analyst or step-up verification before decision |

Pending is common when risk signals conflict but manual intervention may justify approval.

## **Case Management**

A Case is typically generated when:

* Borrower profile changes shortly before request (ATO suspicion)
* Loan request is high-value relative to user history
* Device/IP suggests collusion or synthetic identity clusters
* Required borrower documentation triggers compliance review

Analysts may escalate or finalize decision inline with lending policies.

## **Example Lending Rules**

|                             |                                                                            |                   |
| --------------------------- | -------------------------------------------------------------------------- | ----------------- |
| **Objective**               | **Rule Concept**                                                           | **Output Status** |
| Prevent loan stacking       | If 2+ applications within 24 hours from same device but different profiles | blocked           |
| Flag high-risk applications | If first-time borrower + amount > profile affordability threshold          | pending           |
| Compliance review           | If income/employment fields missing or inconsistent                        | pending           |
| Detect synthetic identity   | If identity score below threshold across combined KYC checks               | blocked           |

Rules allow business teams to control exposure while enabling automation.

## **Summary**

ProfiledRisk supports credit operations by:

* Preventing high-risk accounts from receiving funds
* Reducing default exposure through behavior-based evaluation
* Ensuring compliance alignment with lending obligations
* Improving analyst efficiency through automated segmentation

This use case should be applied whenever borrower exposure or credit risk changes.