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:
MethodNamePhysical	Mandatory. Must be “OrigUpdate”.
CLSUsername	Mandatory. CLS login’s username with update permissions in Origination.
CLSPassword	Mandatory. CLS login’s password with update permissions in Origination.
CLSPIN	Mandatory. PIN generated by Generate_PIN using the same login.
EMail	Mandatory. EMail address to receive funding email.
ApplicationNumber	Mandatory. The SBA application number. One of these 3 is required.
LocationId	Mandatory. The lender’s SBA Location Id as a cross-check of ApplicationNumber.
Requested Amount	Mandatory. The application’s requested amount as a cross-check of ApplicationNumber.
RequestedData	Mandatory. XML or JSON in SBA_ETran format. Supported versions are 3.8i and 4.0+.
SoftwareVendorCode	Mandatory. A private code that authorizes use of SoftwareVendorName.
SoftwareVendorName	Mandatory. Value from Code Tables, Vendor Table.
ErrTyp	Optional. 1 (English) or 2 (XML, default) names in validation error messages.
FormatIn	Optional. Format of RequestData. XML or JSON. See Format IN/OUT Defaults
FormatOut	Optional. Format of ResponseData. XML or JSON. See Format IN/OUT Defaults
Keys of the Output Structure:
ErrorMessageEnglish	Should be nullstring. If not, a generally-worded error message.
ErrorMessageTechnical	Should be nullstring. If not, a more helpful error message, but scarier to some users.
PasswordUpdateRequired	“Yes”, “No”, number of days till expiration or “TBD” (prior to validating login).
ResponseData	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:

<LoanApplication> subelements that are given override existing values on the SBA’s database. All other values (not given among the <LoanApplication> subelements) are left as-is on the SBA’s database. (Note the similarity to the Servicing Web Service.)

<Interest>, <Injection> and <UseOfProceeds> use “delete and insert logic”. That is, all existing entries are deleted from the database and the contents of the XML elements are inserted without worrying about creating a duplicate or unique index violation. These 3 XML element types are processed independently. For example, existing injection data is predeleted only if <Injection> elements are given.

Participants (<Borrower>, <BorrowerRace>, <Guarantor>, <Principal> and <PrincipalRace>) also use “delete and insert logic”, but as a group. So if any one of these 5 tags is given, all underlying borrower, guarantor, principal and race data are predeleted from the SBA’s database, and all <Borrower>, <BorrowerRace>, <Guarantor>, <Principal> and <PrincipalRace> data associated with the application must be given again.

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>
</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.