Method OrigUpdate
This web service allows updates to be posted to loan applications in process and submit the app for funding. The loan application may be any you’re allowed to update whose status is Application In-Process. The only supported XML formats are versions 3.8i and 4.0+.
SOAP Component: | https://catweb.sba.gov/elend/ws/elend.wsdl |
SOAP Method: | SharedEntryPoint, only input is structure Inputs |
Or: | SharedEntryString, only input is JSON string InputString that decodes to a structure |
REST Component: | /rest/elend/flexible |
REST Method: | /rest/elend/flexible/SharedEntryPoint, only input is structure Inputs |
Or: | /rest/elend/flexible/SharedEntryString, only input is JSON string InputString |
Keys of the Input Structure: | |
Mandatory. Must be “OrigUpdate”. | |
Mandatory. CLS login’s username with update permissions in Origination. | |
Mandatory. CLS login’s password with update permissions in Origination. | |
Mandatory. PIN generated by Generate_PIN using the same login. | |
Mandatory. EMail address to receive funding email. | |
Mandatory. The SBA application number. One of these 3 is required. | |
Mandatory. The lender’s SBA Location Id as a cross-check of ApplicationNumber. | |
Mandatory. The application’s requested amount as a cross-check of ApplicationNumber. | |
Mandatory. XML or JSON in SBA_ETran format. Supported versions are 3.8i and 4.0+. | |
Mandatory. A private code that authorizes use of SoftwareVendorName. | |
Mandatory. Value from Code Tables, Vendor Table. | |
Optional. 1 (English) or 2 (XML, default) names in validation error messages. | |
Optional. Format of RequestData. XML or JSON. See Format IN/OUT Defaults | |
Optional. Format of ResponseData. XML or JSON. See Format IN/OUT Defaults | |
Keys of the Output Structure: | |
Should be nullstring. If not, a generally-worded error message. | |
Should be nullstring. If not, a more helpful error message, but scarier to some users. | |
“Yes”, “No”, number of days till expiration or “TBD” (prior to validating login). | |
XML or JSON in SBA_ETran_Response.xsd format. |
For examples of calling flexible, structured methods, see Flexible Structure of Inputs For an explanation of REST calls, see Calling Rest Methods
See “Notes on SBA_ETran_Response formatted XML or JSON”, Notes on SBA_ETran_Response
Updating an existing loan application is a complex task. Perhaps only a little bit of information has to be updated, so the updates should be minimal. (If an XML element isn’t given, it’s assumed not to have changed.)
The Servicing Web Service (currenly Servicing2) has been doing this sort of XML processing for over a decade. But OrigUpdate is the first method to allow lenders to update an existing application. Since the XML implications are extensive, they are explained in-depth here.
XML Application Implications
XML Version 3.8i Differences when Updating an Existing Application
Version 3.8i is a subset of 3.8 restricted to the following, which update in 3 different ways:
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:
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:
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>
</SpecialPurpose>
(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.