XSD for SBA_ETran 8.2, Servicing. Publication Date: 02/06/2025. To view the full content, you must right click the page and select "View Page Source". General Information The following XSD documents <SBA_ETran version="8.1"> and its subelements for all SBA Electronic Lending - Servicing web service methods. As of 08/01/2024, there are two such methods, Servicing2 and Servicing3. Like Origination, there are 3 kinds of complexTypes with subelements (the root, transaction-level and table-level elements). In Origination, the transaction-level element is <App>, and in Servicing, the transaction-level element is <SBALoan>. So that's the first difference. It's also the first similarity, in the sense that everything inside the transaction-level elements will either "commit" or "roll back" as a unit. The table-level elements (or "table tags") have mostly the same name between Origination and Servicing. But that doesn't imply that they contain the same subelements. (They often do, but not necessarily.) Table tags also have "action attributes" that specify what you want to do with the data. The first Origination web service methods allowed only action="insert". But in Servicing, table tags could have action="update", action="delete", etc, as well. Subelements of table tags are called "column tags". They represent individual data elements. Currently, SBA_ETran column tags never have subelements. Missing Elements Origination and Servicing diverged as to how they handled missing elements. In Origination, missing elements were always treated as having no value. In Servicing, missing elements are treated as requiring no change. This was true both at the group level (table tags) and at individual data element level (column tags). But since that time, Origination has defined new web service methods that update loan applications, and Servicing has always had the ability to insert new rows with most table tags. So now missing element rules are now more accurately based on the table tag's action attribute, as follows: Regardless of Origination or Servicing, \ if a table tag has action="insert", missing column tags are always treated as having no value (also known as null or nullstring). If a table tag has action="update", missing column tags are always treated as indicating no change from the existing data already received by the SBA. Therefore, you would have to actually give an element to nullify it (change its value to the nullstring). If a table tag has action="delete", it must also contain all "prime key" column tags necessary to identify which table row is to be deleted. (Other column tags allowed by the table tag may also be given, but there would be no point in doing so.) For example, in Guarantor, only TaxId and BusinessPersonInd are mandatory, because those 2 elements are necessary to indicate what Guarantor you're deleting (or inserting or updating). Because of how action="update" is handled, almost all table and column tags in this XSD are now identified as optional (minOccurs="0"). The only exceptions are prime keys (table-specific column tags necessary to identify the associated table row). XSD Validation Is Not the Same Thing as Business Rules Validation Just because some XML in SBA_ETran format passes validation with a validating parser and this XSD, that does NOT imply that the SBA will accept the transaction. The SBA implements loan programs established by the United States Congress, loan programs whose business rules must, by law, be obeyed. Those rules are almost always too complex to be encoded into XSD syntax. So all XML submissions are subject to additional business rule validations (on SBA servers). For example, in the Origination XSD, SBA_ETran.App.LoanApplication.RequestedAmt is defined with minOccurs="0". That's because, if you need to call OrigUpdate with <LoanApplication action="update"> to update <FrnchiseName>, there's no intrinsic need to update the requested amount in the same call. So in that situation, you wouldn't have to code a <RequestedAmt>. But even if the resulting XML passes validation with a validating parser and the SBA_ETran version's XSD, that doesn't compel the SBA to approve the submission and write a blank check. That example is not entirely facetious. There are rules that XML Schema Definition language simply cannot encode. Adhering to SBA_ETran XML format is just one of many validations that SBA_ETran XML must obey to be accepted as a loan application or loan update by the SBA. The SBA's "root tag" (<SBA_ETran>) for Servicing must contain at least one <SBALoan> tag. It may contain more than one. If more than one <SBALoan> tag is given, each <SBALoan> tag will commit to the SBA's database, or roll back from it, independently of all other <SBALoan> tags in the same submission. For this reason, <SBALoan> is sometimes referred to as the "transaction tag" of Servicing. When ExtractServicing extracts a loan as XML, one of the options is to specify the reason for the extract. It's for the caller's benefit and of no consequence to the SBA what that reason might be. It's declared in this XSD just to keep the presence of a reason attribute from throwing an error. In case the caller is editing an extract to resubmit it, this saves a little unnecessary editing. Your "root tag" should be <SBA_ETran version="5.9"> for XML that conforms to this XSD. See SBA_ETranTypes.xsd for an explanation of ETran version numbers and their coding implications.