It is not recommended that you make a non-member fill out both a loan application and then go through MAP/MOP after that.  The way these work currently, there is no way for the system to know those completely independent applications have anything to do with each other. 

Normally, when a non-member loan app is submitted, a non-member record is created.  In the normal workflow of an employee approving that app via CU*BASE, the data is moved from the non-member table to the MASTER table for the new membership.  Likewise, when a non-member fills out a membership app and goes through the MOP process, the system temporarily creates a non-member record, then moves it into the MASTER file when the approval process is complete. 

When both processes try to create a non-member record with the same SSN, that's when the conflict comes in.  In fact, if you have someone submit a non-member loan application and then use MOP, the system will delete the information from the loan application request, and that will need to be recreated.

This is because of how the system must deal with potential conflicts when unauthenticated data comes in via an online channel, and the incoming data matches data that’s already stored in CU*BASE.  The computer cannot just assume that it’s really the same person, when in fact it could be a fat-finger error on a SSN, or even a fraudulent attempt to pretend to be someone else.  Since non-member records could exist because they are joint owners or co-borrowers on existing member accounts, we cannot simply overwrite or use existing data without manual intervention to verify they are in fact the same person.
 
Also, while CU*BASE does have the capability of creating multiple memberships under the same SSN (because the MASTER file is organized by account base), the CU*BASE non-member files cannot have two records with the identical SSNs, since those files are organized by SSN.  So an online loan app for a non-member creates a non-member record.  But then MAP/MOP tries to process that same person, and because there’s a duplicate SSN, it needs to be able to handle that without inadvertently overwriting existing data.  

We’ve worked very hard but there currently is no one-size-fits-all, elegant solution to all of the potential situations.  We are looking into ways to link the two processes so that the system can trust the incoming data won't accidentally interfere with existing data, but these projects are still in the very early design phases.