Edge Cases and Limitations

Edge Cases

Cross-branch payment that would close a transaction

• Scenario: Payment is collected in a non-owning branch and the amount would fully close the transaction.
• Expected behavior: System rejects posting that closes the loan when the collecting branch is not the transaction-owning branch. Partial payments from another branch can still succeed when within rules.
• Action: Route the customer to the owning branch—or split the workflow so closure is processed there.

Duplicate payment reference on the same loan

• Scenario: The same reference number is used twice on one transaction (e.g. network retry or user error).
• Expected behavior: Second post is rejected (idempotency).
• Action: Use a new reference if it is genuinely a second payment; keep originals for retries.

Invalid payment dates

• Scenario: Payment date is in the future, or before the loan’s accrual start.
• Expected behavior: Post rejected.
• Action: Correct the date to a valid business day.

Payments while status is AUCTION

• Scenario: User tries to post a payment after the loan is marked AUCTION.
• Expected behavior: Post rejected.
• Action: Follow branch policy for auction-stage handling (outside normal repayment path until defined otherwise).

Customer overpayment

• Scenario: Cash received exceeds principal + interest + discounts due.
• Expected behavior: Surplus may be recorded as customer advance for later use (closure, release, top-up—per workflows).
• Action: Explain to customer how advance appears on their profile and receipts.

Blocked customer with existing active loans

• Scenario: Customer is blocked after one or more transactions were already active.
• Expected behavior: New transactions are not allowed, but repayment and closure on existing transactions are allowed.

Early closure in first 30 days

• Full closure day 1 to 15: minimum 15-day interest.
• Full closure day 16 to 30: full 30-day interest.
• Partial payment within first month: daily interest up to payment date.

Missing daily gold price

• Scenario: Branch has not entered gold price for the business date.
• Impact: Risk valuation and release valuation may be blocked or inaccurate.
• Action: Enter daily gold price before release or risk operations.

Duplicate civil ID attempt

• Scenario: User tries to create a new customer with an existing civil ID.
• Expected behavior: System prevents duplicate creation.
• Action: Search and use existing customer profile.

Post-creation civil ID change

• Scenario: Civil ID requires correction after customer creation.
• Expected behavior: Only Head role can update civil ID.
• Action: Escalate the request to Head for controlled update.

Limitations and Scope Boundaries

• Full auction liquidation workflows are out of scope; marking AUCTION is supported mainly to freeze normal interest and repayment behaviour until policy extends the product.
• Automated legal notices are out of scope.
• SMS and WhatsApp integration are not included in current scope.
• Mobile app is out of scope for this phase.
• Gold barcode tagging is not included.

Resolved Policy Decisions

• Customer creation authority:

  • Head: allowed
  • Branch Manager: allowed
  • Staff: allowed

• Block customer authority:

  • Head and Branch Manager

• Payment entry authority:

  • Head, Branch Manager, and Staff are all allowed

• AUCTION status authority:

  • Head, Branch Manager, and Staff are all allowed

• Civil ID evidence:

  • Front and back images should be captured per branch KYC policy; the system persists secure URLs and may enforce uploads in your configuration

• Payment reference number:

  • Required on each posted payment; must be unique per transaction to prevent duplicate posting

• Interest calculation on posting:

  • Authoritative accrued interest comes from the server at post time (previews may differ slightly if used only as estimates)

• Gold release eligibility rule:

  • Release is allowed only when released gold value does not exceed outstanding principal

• Gold valuation formula (single standard):

  • value = net weight x (purity / 100) x daily gold rate
  • This same formula must be used in release, risk, and valuation safeguards

• Discount alert visibility:

  • Branch Manager and Head must both receive discount alerts

• Top-up workflow scope:

  • Treated as supported only through closure and re-issue workflow

Operational Warnings

• Payment deletion is not allowed.
• Financial and status changes are audit-logged and immutable.
• Internal financial precision is 3 decimals; displayed values round to 2 decimals.
• Interest model is simple interest only; no compounding.

Workflow Prerequisite Checklist

Use this quick check before sensitive operations:

1. Customer is active and valid.
2. Transaction status is ACTIVE.
3. Daily gold rate is present.
4. Branch ownership rules are respected.
5. Required reason fields are completed (for discount or blocking actions).
6. A unique payment reference is ready before posting.