XML Application Implementation Issues

XML Version 4.0+ Differences when Updating an Existing Application

Version 4.0 represents a major expansion of elements allowed in Origination Update and Underwriting. It allows all the same elements as are allowed in Origination web services. However, some elements may not be used in the context of updating an existing loan application (just like the Origination web pages). Specifically:

On an existing loan application, Location ID cannot be changed. Therefore the XML element<LocationId> (and its parent, <PartnerInformation>, which has no other elements besides <LocationId>) cannot be given.

On an existing loan application, processing method cannot be changed. Therefore the XML element <ProcessingMethodCd> cannot be given.

If the underwriting authority for the application is SBA, it cannot be changed to LNDR. A lender’s decision to forgo underwriting authority and instead defer to SBA underwriting is irrevocable. Therefore, <UnderwritingBy> element can be given, but only if it contains SBA.

Some data relating to the SBA’s own credit scoring of an application are represented in version 4.0 as elements <CreditReport>, <CreditScore> and <LiquidCreditScore>. Those elements cannot be given by non-SBA users of Origination Update. It’s more restrictive than that, in fact. Only SBA underwriting loan officers (“reviewers”) may enter them. So if an SBA reviewer calls the Origination Update web service, the XML may contain those 3 elements. But if anyone else, who is not an SBA reviewer, calls Origination Update with any of those 3 elements, it will result in an error.

All of these same considerations apply to the Underwriting Web Service because it too updates an existing application.

XML 4.0+ Action Attributes and “Prime Keys”

A problem with the automatic delete-and-insert logic of version 3.8i, described above, is that, under its own rules, a “delete all” cannot truly be done. For example, if there’s only one injection item, and that item is no longer part of the application, there’s no way to delete it. In order to trigger the pre-deletion of all injection, you would have to give an <Injection> element. And once you do that, under delete-and-insert logic, you’re inserting a new injection item. Under version 4.0+, delete-and-insert logic no longer happens automatically.

Beginning with version 4.0, Underwriting and Origination Update web services can control deletion, insertion and update of table rows explicitly, manually, with the action attribute. This technique will be very familiar to users of the Servicing web service (now called Servicing2, see Method Servicing2), which has always used action attributes. Every table-level element is allowed to have an action attribute, whose value is generally “delete”, “insert” or “update”. In web services that can only create a new application (such as Originate3 or OrigScore), “insert” is assumed and need not be given on table-level elements. But web services that operate on existing applications (such as Origination Update or Underwriting), the action attribute assures that the sender and receiver are “on the same page” as to what should be done with the data.

Beginning with version 4.0, almost all table-level elements contain identifying column-level elements, called “prime keys” meant to distinguish the real-world person or thing to which it refers. For example, in SBA_ETran XML, every participant (<Borrower>, <Guarantor> or <Principal>) is identified by 2 prime keys: <TaxId> and <BusinessPersonInd>. A borrower person is distinguished from a borrower business with the same TaxId. For example, a sole proprietorship is a business, which is distinguished from the person who has the exact same TaxId.

Action attributes interact with prime keys (if any) to determine whether a miscommunication has occurred:

When inserting a table-level element, its prime keys must not match a pre-existing row on the SBA’s database (for the same application and table). If it does, it’s an error that should be investigated.

When deleting or updating a table-level element, its prime keys must match a pre-existing row on the SBA’s database (for the same application and table). If not, that kind of error must also be investigated.

Manually Specifying Delete-and-Insert Logic for Some Table-Level Elements

Although delete-and-insert logic doesn’t happen automatically in XML 4.0+ anymore, some table-level elements allow manually requesting delete-and-insert logic by giving action="deleteall" on the first occurrence of the element in the application. This allows remaining occurrences (of that same table-level element in the same application) to specify action="insert". This eliminates concern as to whether or not inserted elements’ prime keys match pre-existing prime keys on the SBA’s database. But consult the XSD to see whether action="deleteall" is allowed. Initially, only table-level elements that consist entirely of prime keys allow action="deleteall" (BorrowerRace, BusAppr, PrincipalRace, SpecialPurpose and UnderservedMarket).

For example, suppose an app currently has special purposes AGRI and EXPT, but you want AGRI and REVL:

<SpecialPurpose action="deleteall"/>
<SpecialPurpose action="insert"><SpcPurpsLoanCd>AGRI</SpcPurpsLoanCd>
</SpecialPurpose>
<SpecialPurpose action="insert"><SpcPurpsLoanCd>REVL</SpcPurpsLoanCd>

(Without the initial action="deleteall", the insert of AGRI would have resulted in an “already exists” error.)

After XML or JSON changes have been applied

After the XML or JSON updates have been applied to the loan application, the application is validated for approval according to usual business rules. If the application fails validation, the XML or JSON changes are committed to the SBA’s database, which leaves the application updated and still in Application In-Process status.

But if the application passes validation, its status advances according to all the standard SBA business rules for the loan application. If its processing method requires credit scoring and it hasn’t already been credit scored, it goes into the queue to be credit scored. If its processing method and lender agreements require SBA underwriting, it goes into an In Review status. And so on.

In other words, except for processing the XML or JSON, and associated updates to the SBA’s database, OrigUpdate is exactly analogous to pressing the Submit button at the top of the Loan Origination web pages.