Closing Costs Detailed Architectural Status

Get Started. It's Free
or sign up with your email address
Rocket clouds
Closing Costs Detailed Architectural Status by Mind Map: Closing Costs Detailed Architectural Status

1. Project Goal

1.1. Increase GFE accuracy vs. actual closing costs to within 10% and 0% tolerances to greatly reduce losses due to inaccuracies.

2. Solution Dimensions

2.1. Automate closing Fee population in NetOxygen for refinance loan origination

2.1.1. Update underlying Ernst interface within COTS version of NetOxygen to properly integrate with enhanced Ernst web service for servicing fee requests.

2.1.1.1. Status

2.1.1.1.1. John Moseley is working on an updated architecture plan for COTS interface to be presented to WIPRO architecture review board this week.

2.1.1.2. Projected Outlook

2.1.1.2.1. Probably a month out before COTS design is completed.

2.1.1.3. Potential Risks

2.1.1.3.1. Little interaction with Ernst to date so potential impact to design if interface requires changes

2.1.1.3.2. MEDIUM - Due to possibility of business logic that is currently unaccounted for.

2.1.1.4. Recommended Action

2.1.1.4.1. Obtain a copy of COTS design so we can insure that all impacts are considered when assessing any design updates that are needed to address requirement gaps.

2.1.2. Update Loan Origination fee calculation screens to account for all information required for USB business rules to properly assign costs

2.1.2.1. Status

2.1.2.1.1. Eric Coleman has begun doing a functional analysis on the BRD to determine what exact screen changes are required to meet stated requirements.

2.1.2.2. Projected Outlook

2.1.2.2.1. Dependency on COTS design so likely 2 months before completion of design.

2.1.2.3. Potential Risks

2.1.2.3.1. Limited interaction with Ernst to determine how Request and Response are specifically structured to insure all required business rules are being properly managed.

2.1.2.3.2. HIGH - Due to lack of clarity in understanding between WIPRO and Ernst as to division of responsibility for all fee processing and exception handling.

2.1.2.4. Recommended Action

2.1.2.4.1. Facilitate loan scenario walk-throughs in order to exercise all of the business rule patternsnecessary to insure all cost models are properly handled across all permutations of states, vendors and costing categories for both CARD and Retail.

2.2. Ernst Centralize fee storage for all USB negotiated closing fees

2.2.1. Capture all rates to be centralized on behalf of USB

2.2.1.1. Standard Vendor Rates

2.2.1.1.1. Status

2.2.1.1.2. Projected Outlook

2.2.1.1.3. Potential Risks

2.2.1.1.4. Recommended Action

2.2.1.2. Negotiated Rates

2.2.1.2.1. Status

2.2.1.2.2. Projected Outlook

2.2.1.2.3. Potential Risks

2.2.1.3. Endorsement rates

2.2.1.3.1. Status

2.2.1.3.2. Projected Outlook

2.2.1.3.3. Potential Risks

2.2.1.4. State Specific Taxes and Fees for Box 4 and 5

2.2.2. Ernst to apply fees and updates within a data management system to which they have direct access

2.2.2.1. Status

2.2.2.2. Projected Outlook

2.2.2.3. Potential Risks

2.2.3. Validate all fees are current and correct before production activation

2.2.3.1. GFE Block 4

2.2.3.1.1. Status

2.2.3.1.2. Projected Outlook

2.2.3.1.3. Potential Risks

2.2.3.2. GFE Block 6

2.2.3.2.1. Status

2.2.3.2.2. Projected Outlook

2.2.3.2.3. Potential Risks

2.2.3.3. GFE Block 7 and 8

2.2.3.3.1. Status

2.2.3.3.2. Projected Outlook

2.2.3.3.3. Potential Risks

2.3. Enhance NetOxygen closing fee assignments for GFE and all other closing and settlement phases to interact with Ernst to request and process required fees.

2.4. Partner with Ernst to create a fee intermediary service for automatically supplying appropriate fee data for title, settlem,ent, inspection and state taxes and fees for all national and majority of local vendors used bu business lines.

2.4.1. Partner with Ernst to initiate a Fee Service to facilitate the collection, population and distribution of all title and settlement related fees (GFE Box 4)

2.5. Facilitate mechanism for monitoring all fees and insuring fee changes and new charges are recognized and updated in a specified timeframe.

3. load testing

3.1. Test Bed

3.1.1. Users

3.1.2. Customers

3.1.3. Loans

3.1.4. Leads

3.1.5. Test Data Distribution Comparable to current portfolio

3.2. Test Scripts

3.2.1. Load Test Script

3.2.2. Generate Loans Scripts

3.2.3. Generate Leads Scripts

3.2.4. Generate Customers

3.2.5. Generate Users and Roles

3.2.6. Data Loading Scripts (ex. credit scores for Price Adjustments)

3.3. test types

3.3.1. Test to Failure

3.3.2. Stress testing

3.3.3. Extended Duration Testing

4. Status

4.1. Automate closing Fee population in NetOxygen for refinance loan origination

4.1.1. Update underlying Ernst interface within COTS version of NetOxygen to properly integrate with enhanced Ernst web service for servicing fee requests.

4.1.1.1. John Moseley is working on an updated architecture plan for COTS interface to be presented to WIPRO architecture review board this week.

4.1.1.2. Probably a month out before COTS design is completed.

4.1.1.3. Recommended Action

4.1.1.3.1. Obtain a copy of COTS design so we can insure that all impacts are considered when assessing any design updates that are needed to address requirement gaps.

4.1.2. Update Loan Origination fee calculation screens to account for all information required for USB business rules to properly assign costs

4.1.2.1. Eric Coleman has begun doing a functional analysis on the BRD to determine what exact screen changes are required to meet stated requirements.

4.1.2.2. Dependency on COTS design so likely 2 months before completion of design.

4.1.2.3. Recommended Action

4.1.2.3.1. Facilitate loan scenario walk-throughs in order to exercise all of the business rule patternsnecessary to insure all cost models are properly handled across all permutations of states, vendors and costing categories for both CARD and Retail.

4.2. Ernst Centralize fee storage for all USB negotiated closing fees

4.2.1. Capture all rates to be centralized on behalf of USB

4.2.1.1. All of theses rates have been sent to Ernst for inclusion in Property Info. Property Info is apparently in the process of adding the 3/23 rates into their database.

4.2.1.2. Standard Vendor Rates

4.2.1.2.1. The stated direction is that the business will maintain all these rates in conjunction with negotiated rates.

4.2.1.2.2. Standard rates from key vendors have been sent to Ernst for inclusion within their consolidated data

4.2.1.2.3. Confirmed with Jackie there is no overlap between standard and negotiated rates within tables.

4.2.1.3. Negotiated Rates

4.2.1.3.1. Jackie is creating an updated version of the fee spreadsheet that has a comprehensive list of all fees currently in scope with specific exceptions called out.

4.2.1.3.2. Need to complete assessment of fee engine to determine likelihood this will meet needs and assess design implications.

4.2.1.4. Endorsement rates

4.2.1.4.1. Jackie's updated spreadsheet includes the updated values for endorsement as well.

4.2.1.5. State Specific Taxes and Fees for Box 4 and 5

4.2.1.5.1. These rates are also included in the updated version of the fee spreadsheet but the values are not all present. Many must be looked up for specific rates.

4.2.1.6. GFE Box 6

4.2.1.6.1. No detailed testing process has been discussed to date for how to test this functionality.

4.2.1.7. GFE Box 7 and 8

4.2.1.7.1. No detailed testing process has been discussed to date for how to test this functionality.

4.2.1.8. OPEN ITEMS

4.2.1.8.1. Property Info rates need to be completely entered for testing to take place.

4.2.1.8.2. State taxes and fees need an ownser for processing updates.

4.2.1.8.3. State taxes and fees require post processing to complete (example - Hawaii charges no Premium tax but a ~4% charge on ALL settlement costs and closing costs)

4.2.1.8.4. Endorsement rates are not currently tested.

4.2.1.8.5. Need a plan for assessing current status of Block 6, 7 and 8 data.

4.2.1.9. RECOMMENDED ACTION

4.2.1.9.1. No detailed testing process has been discussed to date for how to test this functionality.

4.2.1.10. KNOWN OBSTACLES

4.2.1.10.1. Current Ernst Web Service test interface is very difficult to use. Need a better alternative.

4.2.1.10.2. Still need a mechanism for validating fees supplied by Ernst against expected values being managed by Business.