Skip to content

Retrieve Existing Credit Report Feature

Overview

This feature allows users to retrieve credit reports that were ordered from MCL (MeridianLink) outside of ReversePilot. This is useful when credit reports exist in MCL but are not visible in ReversePilot.

Implementation Details

Backend Changes

1. Constants (apps/credit_report/constants.py)

Added two new XML payload templates: - RETRIEVE_INDIVIDUAL_CREDIT_REPORT_PAYLOAD - For retrieving individual credit reports - RETRIEVE_JOINT_CREDIT_REPORT_PAYLOAD - For retrieving joint credit reports

Both templates use StatusQuery as the CreditReportRequestActionType and include a VendorOrderIdentifier field that gets populated with the order number.

2. Utils (apps/credit_report/utils.py)

Added three new helper functions: - retrieve_individual_credit_report(user) - Prepares individual retrieve payload with headers - retrieve_joint_credit_report(user) - Prepares joint retrieve payload with headers - set_retrieve_payload_values(payload, order_identifier, borrower_data) - Sets the VendorOrderIdentifier and real borrower information (name, SSN) in the XML payload to replace test data

3. Views (apps/credit_report/views.py)

Added new endpoint: - POST /credit-report/credit-reports/retrieve_existing_report/ - Request Body: json { "borrower_id": "string", "order_identifier": "string", "is_joint": boolean } - Uses the same MCL endpoint: https://cic.meridianlink.com/inetapi/request_products.aspx - Implements duplicate request prevention using Redis-backed locking - Processes the response using existing process_credit_report() function - Returns the same response format as ordering a new credit report

Frontend Changes

Credit Component (src/pages/LoanDetail/components/ActiveBorrower/components/Credit/index.vue)

  1. New Button: Added "Retrieve Existing Credit Report" button in the action buttons section

  2. New Dialog: Added retrieve dialog with:

  3. Input field for order number
  4. Automatic detection of individual vs joint report based on number of borrowers
  5. Validation for required order identifier

  6. Clear user instructions

  7. New State Variables:

  8. isOpenRetrieveDialog - Controls dialog visibility
  9. retrieveOrderIdentifier - Stores the order number entered by user

  10. validationRetrieveIdentifier - Stores validation error messages

  11. New Methods:

  12. handleRetrieveExistingReport() - Opens the retrieve dialog
  13. validateRetrieveIdentifier() - Validates the order identifier input
  14. handleConfirmRetrieveDialog() - Processes the retrieve request
  15. handleCloseRetrieveDialog() - Closes dialog and resets state

Usage

For Users

  1. Navigate to the Credit tab of any borrower
  2. Click the "Retrieve Existing Credit Report" button
  3. Enter the MCL order number (e.g., 10430844 or 10548570)
  4. Click "Retrieve"
  5. The system will automatically determine if it's an individual or joint report based on the number of borrowers
  6. The retrieved credit report will populate the Credit tab with all account information and summary data

Testing Order Numbers

For testing purposes, use these order identifiers: - 10430844 - 10548570

Technical Notes

How It Works

  1. User enters an order identifier
  2. Frontend determines if report should be individual or joint based on borrower count
  3. Backend constructs appropriate XML payload with StatusQuery action type
  4. Backend extracts real borrower data (name, SSN) from the database and replaces test data in the payload
  5. Request is sent to MCL's request_products.aspx endpoint with real borrower information
  6. MCL returns the existing credit report data
  7. Backend processes response using existing credit report processing logic
  8. Frontend displays the retrieved data in the same format as newly ordered reports

Key Differences from Ordering New Reports

  • Uses StatusQuery instead of Submit as the action type
  • Requires VendorOrderIdentifier in the payload
  • Does not charge for a new credit report pull
  • Retrieves existing data rather than pulling fresh data from bureaus

Duplicate Request Prevention

  • Uses Redis-backed distributed locking (10-second timeout)
  • Prevents multiple simultaneous retrieve requests for the same order
  • Returns HTTP 202 if a request is already in progress

Error Handling

  • Validates required fields (borrower_id, order_identifier)
  • Proper boolean conversion for is_joint parameter (handles string values like "false", "true")
  • Handles MCL API errors gracefully
  • Provides user-friendly error messages
  • Clears cache locks on exceptions

Security & Data Integrity

Real Borrower Data

The retrieve functionality does not send hardcoded test data to the MCL API. Instead: - Borrower information (FirstName, LastName, MiddleName, SuffixName, SSN) is extracted from the actual borrower record(s) in the database - Test data in the XML templates is replaced with real data before sending to MCL - For joint reports, both borrowers' data is populated from the loan's associated borrowers - This ensures MCL receives accurate borrower information for validation and logging

Boolean Parameter Handling

The is_joint parameter is properly converted to boolean to prevent issues: - Handles string values: "true", "True", "false", "False", "1", "0", "yes", "no" - Case-insensitive string comparison - Prevents string "false" from being treated as truthy - Ensures correct payload type (individual vs joint) is always used

Future Enhancements

  • Add ability to manually specify individual vs joint instead of auto-detection
  • Add order history/search functionality
  • Implement batch retrieval for multiple orders
  • Add order number validation/format checking