Introduction

The Sherman Calculation Engine with XML Interface (SCEX) is a lightweight suite of lending, depositing, compliance, and support modules that provides lenders with a lightning-fast API tool to meet all calculation needs.

The SCEX is secure - neither receiving, retrieving, storing, or exporting any information particular to any individual. Being free of proprietary user information means being free of the security concerns associated with disclosing personal information to a 3^rd party vendor. By focusing exclusively on the math, the SCEX slims down to focus on computing quick calculations exclusively.

Getting Started

Each solution for the SCEX has its own particular technical platform configurations. To assist your technical team get up and running, we offer:

• SCEX Project History - A quick historical overview of the SCEX project.
• Installation Instructions - How to properly integrate the SCEX calculation engine into your platform.
• Implementation Assistance - Once physical access to the engine has been established, get connected to the SCEX with your particular software solution.
• Module Structure - An overview of the structure common to the modules found implemented in the SCEX.
• Legend - Understand quick identifier conventions used in this manual.

Module Overview

Now that the SCEX is up and running and queries can be run, get assistance on how to craft xml payloads to correctly represent your calculation request and review the result structures for consuming the solutions.

Loans

The SCEX provides a broad spectrum of closed-end loan computation tools, which over the years has culminated with our flagship module, LoanBuilder.

• LoanBuilder is designed to compute any loan from any lending market in any country ¹. The particulars of a loan are added, element-by-element, to reflect precisely the particulars of that loan.

The modules that follow are all legacy modules for single advance, specific repayment structure loans.

• Equal Payments - Compute an equal payment loan.
  • Compute Payment
  • Compute Proceeds
  • Compute Term
• Balloons - Specify the amortization term, regular payment or balloon.
  • Specify Regular - Specify the regular payment to compute the balloon.
  • Specify Final - Specify the final balloon payment to compute the regular payment.
  • Specify Amortization Term - Specify a long term amortization to compute a regular payment and balloon at the short term call.
• Single Payment Notes - Term or Bridge Loans where one borrows cash and pays off the loan with a single payment at maturity.
• Interest Payments - These modules are for loans that focus on payments paying off interest, with or without a specified principal reduction.
  • Interest Only - Pay only interest until the final balloon payment.
  • Fixed Principal Plus Interest - Pay interest and specified amounts of principal.
• Skips, Pickups, Irregular - Skip payments, or specify payments or specify additions to regular payments (Pickups) with these modules.
  • Skipped and Irregular Pmts - Skip payments and specify payment amounts with this module.
  • Skipped and Pickup Pmts - Skip payments and boost regular payments with this module.
• Mortgage Loans
  • ARM - Adjustable Rate Mortgages - Teaser Rate and Term precede an evolving interest rate.

Open-End Lending

Support for open ended lending is available through the SCEX in two fundamental ways:

• Initial Disclosure - The initial disclosure for an open ended loan is done with a closed-end loan module. We recomment Loan Builder for this purpose.
• Periodic Disclosures - Lines of credit require periodic minimum payment disclosure and payoff information. Use the linked module for periodic disclosures.

Loan Servicing

As the servicing of a loan continues, various information may wish to be explored, such as given the current state of the loan, what new payment would be computed? The Loan Builder module should be used for all loan Servicing needs.

Deposit Modules

The SCEX comes with several common deposit modules, broadening your suite of solutions. They are as follows:

• Annuities - Streams of income paid in a series of regular monthly payments.
• Certificates of Deposit - Compute CD payoffs and APY's
• Individual Retirement Accounts - Compute retirement payments or the payment to produce a retirement income goal.

Compliance Modules

Loans require specific sets of mandated disclosure quantities. The SCEX comes with several modules to assist lenders to determine several critical quantities. These modules are as follows:

• APR Module - Compute the regulatory Annual Percentage Rate along with all relevant supporting data to prove compliance to an examiner.
• APY Module - Compute the annual percentage yield for a deposit.
• HCM - High Cost Mortgage - Determine if the loan is a High Cost Mortgage plus the triggers causing it to be one.
• HPML - High Priced Mortgage Loan - Determine if the loan is a High Priced Mortgage Loan with supporting data.

Miscellaneous Modules

Several solutions in the SCEX are unique modules, which are as follows:

• Dealer Reserve - Dealers can calculate their portion of the finance charge when they, themselves, have financed vehicles with this module.
• Refunds - Single Premium insurance products may require refunding part of the original premium when a loan is paid off early.
• Auto Assist - The various taxes and fees are computed and bundled with the Auto Assist module.

Diagnostic Modules

The SCEX provides several diagnostic and data reporting modules for a more robust solution. These modules are as follows:

• Version - Reports the version of the SCEX being used.
• Account Listing - Lists all available solutions represented by setup files currently operating with the SCEX, each solution represented by a positive Account integer.
• Input Tool - The setup files for a given account solution are queried with this module, revealing all of the protection products and parameters active for that account. This reporting tool may be used by clients designing a responsive user interface to the particulars of a client solution.
• Setup Cache - This module is a dynamic version of the "Account Listing" module, and queries the currently running SCEX to limit and list all currently Setup Files in active cache.

This powerful suite of calculation modues will provide your company with the tools necessary to fully represent all of the loan products. As importantly, should capability or functionality be lacking, contact Sherman and Associates at support@shermanloan.com to modify the SCEX to include the new functionality.

The SCEX is a constantly growing engine and represents the accumulation of lending intelligence over decades of use. Quarterly releases announce this new functionality which may or may not be implemented depending on whether or not the new functionality is needed.

^1. Only ARM's requiring TILA RESPA data are not currently supported by LoanBuilder. For these loans, choose the ARM module defined above.

PROJECT HISTORY

In the Beginning

The development and consulting team here at J. L. Sherman and Associates has accumulated over sixty man-years of experience creating a comprehensive array of programs providing complex, accurate, and compliant loan calculations for our clients. All of this experience and expertise goes into our Sherman Calculation Engine (SCE) - the most robust loan quotation engine on the market.

Prior to the development of our desktop based loan quotation software for the 32-bit Windows platform (see WinLoan32), several of our customers expressed an interest in having access to the calculation routines contained in the WinLoan16. Due to previous design decisions, this was not possible. With Winloan32, however, the powerful calculation engine that is the foundation of our end-user loan quotation software (both WinLoan32 and eWinLoan) was developed as a separate product, which we call the Sherman Calculation Engine (SCE).

The SCE was released as a product in the form of a 32-bit dynamic link library (DLL) for the Windows environment. Loan and insurance setup information is stored in text files that are created and maintained by Sherman's technical support team. Depending upon the level of support you desire, we can handle all of the steps in setting up a new account for you. This process involves gathering samples from the client and payment protection provider, and thoroughly testing to ensure that the final calculation results match what the client is expecting.

By separating the calculation logic from the user interface, we make available to our partners all of our applied knowledge and expertise. However, our new partners encountered three problems as they worked to interface directly with the SCE:

1. Initially, the user of the SCE needed to implement all of the data structures used by the SCE for input and output, as well as create the interface to the functions found in the DLL.

2. As the SCE was modified to suit customer needs and federal or state regulations additions and changes, these data structures needed to be altered. This required the data structures in our partner’s applications to also be altered, and then the applications which call the SCE must be recompiled.

3. Some of our partners wanted to access the power and functionality of the SCE from applications not written for the 32-bit Windows platform. There is no simple way to access a 32-bit Windows DLL from another platform.

These three problems prompted Sherman and Associates to begin development on two new satellite projects of the SCE: the SCEX XML interface (hereafter called the SCEX) and the SCE Loan Server.

Emergence of the SCEX

The SCEX addresses problems number one and two in the list above. It provides an XML interface wrapped around the SCE. By using the SCEX instead of the SCE, the calling application no longer needs to duplicate the data structures used by the SCE. Instead, all input sent to the SCEX is contained in one character buffer (or character string). Similarly, the SCEX returns all results in a single character buffer, which the calling application must provide.

The format of the text contained in these character buffers is what the "X" in the SCEX is all about - XML. XML is a simple, flexible text format which is platform independent and extensible and is playing an increasingly important role in the exchange of data between disparate platforms and systems.

The SCEX alleviates problem #1 by doing away with complex input and output data structures all together. Instead, the application calling the SCEX provides the necessary input in a character buffer, which contains the XML data. As an example, here is the XML input data for a 36 month equal payment loan based on a 10% interest rate and $10,000:

<inLOAN_BUILDER>
   <EditInterest Date="2019-01-01" IntRate="10.000" AccrualCode="320" />
   <Advance Date="2019-01-01" Amount="10000.00" />
   <PmtStream Begin="2019-02-01" Term="36" />
</inLOAN_BUILDER>

The result of the loan calculation is then passed back to the calling application in a buffer. The application then need only parse the returned XML to use the calculation results as appropriate. Here is a sample result returned from the SCEX, using the inputs specified above (with the amortization table turned off):

<outLOAN_BUILDER>
    <Results>
        <Description>Successful Calculation</Description>
    </Results>
    <FedBox>
        <AmtFin>10000.00</AmtFin>
        <FinChg>1615.40</FinChg>
        <TotPmts>11615.40</TotPmts>
        <RegZAPR Type="Actuarial">9.995</RegZAPR>
    </FedBox>
    <Moneys>
        <Proceeds>10000.00</Proceeds>
        <Principal>10000.00</Principal>
        <Interest>1615.40</Interest>
    </Moneys>
    <Accrual>
        <Method>Actual/365 USRule</Method>
        <Days1Pmt DayCount="Actual">31</Days1Pmt>
        <Maturity>2022-01-01</Maturity>
    </Accrual>
    <PmtStream Term="36" Pmt="322.65" Rate="10.000" Begin="2019-02-01" PPY="12"/>
</outLOAN_BUILDER>

Furthermore, the second problem mentioned above is also handled. If a new input or output data field is added to the SCE, then the appropriate XML input/output tags will also be added to the SCEX. Applications which do not require this new functionality will not need to be recompiled. Instead, they will simply not provide the new input field, or not recognize the new output field. So long as your application does not require the use of the new data fields, then no recompilation is necessary!

Installation

System Requirements

The SCEX is developed with the most minimal computer requirements in mind. As mentioned earlier, it originated as a 32-bit Windows product, but our list of supported platforms has expanded to include 64-bit Windows and Linux on the Intel/AMD 64-bit architecture. The SCEX may be installed on computer hardware as lean as an old Pentium 3 laptop with 64 megabytes of RAM, and at least 7.5 megabytes of hard drive space running Windows 98.

The SCEX Loan Server must be installed on a more recent version of the Windows platform - Windows 2000 / XP / 2003 / Vista, as Windows 98 and earlier do not support services.

Summary of System Requirements

Processor: Pentium IV class processor is recommended, although the SCEX can function on a 486 CPU.

RAM: As needed by your choice of operating system.

Disk Space: 7.5 megabytes.

OS: 32/64-bit Windows, or Linux on Intel/AMD 64-bit architecture (specifically, the latest stable release of Ubuntu Linux). To use the SCEX Loan Server, Windows 2000 or later is required to host the service. Any operating system capable of communicating over TCP/IP may access the SCEX Loan Server. Once you have received the SCEX installation package (via download from Sherman and Associates’ web site), you are ready to install the SCEX.

Version Information

The SCEX is distributed as a Windows self-extracting executable. The name of the installation file will be in the form of scex_installer-x.y.z.exe for the full version SCEX, or scex_demo_installer-x.y.z.exe for the demonstration version of the SCEX.

The x.y.z portion of the installer file name refers to the version of the SCEX contained within. Sherman and Associates has chosen to standardize versioning information based upon dates and releases, instead of arbitrary version numbers. Specifically, the first part of the version number (x) refers to the year of the release. The second part of the version number (y) refers to the month of the quarterly release. As it currently stands, the quarterly releases will be made in January, April, July, and October. Thus, the value of y will always be in {1, 4, 7, 10}. Finally, the last part of the version number (z) signifies the release number for the given quarter, with zero (0) signifying the first release of the quarter.

Hence, a version number of 2005-07-0 refers to the first release of the SCEX for the July, 2005 quarter. Similarly, a version number of 2006-01-02 refers to the third release of the SCEX in the January, 2006 quarter.

Note that the version number of the installer corresponds with the version number of all applications and dynamic link library (DLL) which make up the SCEX. In this manner, it is very easy to verify that you are using the correct version of the DLL and applications, instead of having different (and arbitrary) version numbers for each, separate part of the library.

Installing the SCEX

To install the SCEX, simply run the scex_installer-x.y.z.exe application. Note that you should install the SCEX from a user account with Administrator privileges. The installer is a standard windows installation application, which will provide you with a few installation options as it executes.

Components to Install

The first installation page will prompt you for optional packages which may be installed with the SCEX, but are not required. If you choose to not install any of the optional components, then the following minimum install of system files and directories will be installed on your computer:

InstallDir\scex.dll
InstallDir\data\*.*
InstallDir\samples\*.*
InstallDir\xml\*.dtd
InstallDir\xml\output\*.dtd

It is important to note that the above set of files are the minimal installation set which will allow for the full use of the SCEX. When integrating your software with the SCEX, these files and subdirectories are the only files which need to be deployed along with your application (with the exception of the samples directory). Also, please note that the subdirectory names and relative locations to the SCEX DLL are critically important, and should not be altered.

Note that the .xml files found in the subdirectories of InstallDir\samples are sample input requests and output responses. Using the SCEX Test Application (see below), you can quickly load one of these sample XML requests and see the results generated by the SCEX.

The following optional SCEX components are also available for installation, and will be installed unless you specify otherwise:

• SCEX Test Application: This executable lets the user enter, load, and save XML queries to send to the SCEX, and then view the result. It is very useful for trying out new XML queries and debugging existing queries.

  The following file(s) are installed if this component is selected:

  ..\InstallDir\sce_tester.exe
  

• SCEX Account Tester Application: This application was originally created by the developers at Sherman and Associates, Inc. to ease regression testing of the SCEX releases. Instead of manually going through a set of samples for each release (which would be slow, error-prone, and hence very difficult), Sherman and Associates created an application to automate the re-testing process. Please see the help available from within this application for further detail.

  The following file(s) are installed if this component is selected:

  ..\InstallDir\AccountTest\*.*
  

• SCEX Manual: What you are currently reading.

  The following file(s) are installed if this component is selected:

  InstallDir\scex_manual.pdf
  

• Sample Source Code: We have provided sample source code which illustrates how to access the SCEX directly, in a variety of programming languages (currently C#, java, vb.net, and Visual C++).

  The following file(s) are installed if this component is selected:

  InstallDir\source\*.*
  

Along with the SCEX, Sherman and Associates includes the SCEX Loan Server. The SCEX Loan Server is only required if your application needs to connect to the SCEX through a TCP/IP interface. By default, the SCEX Loan Server is not installed. The following components may be installed for the SCEX Loan Server, if selected by the user:

• System Files: In order to run the SCEX Loan Server Service, these system files must be installed. The service is not only installed in the installation directory, but also registered and started. Please see Appendix A and the LoanServerService-README.txt files for more information on the SCEX Loan Server.

  The following file(s) are installed if this component is selected:

  InstallDir\LoanServerService.exe
  InstallDir\LoanServerService-README.txt
  

• Sample Source Code: We have provided sample source code illustrating how to access the SCEX Loan Server, using a variety of programming languages (currently C, C#, Delphi, Java, PHP, and python).

  The following file(s) are installed if this component is selected:

  InstallDir\source\loanserver\*.*
  

Installation Folder

As in most Windows installation applications, you are free to select a folder in which the SCEX and its associated files will be installed. NOTE: If you are also installing the SCEX Loan Server Service, make sure that you install the files on a local drive. Please see Appendix A for more information.

Created Shortcuts

One or more shortcuts will be created in the Windows Start Menu, and will be accessible for all users. You will find these newly created shortcuts in Start ▸ All Programs ▸ Sherman and Associates ▸ SCEX.

• Uninstall SCEX: This shortcut links to the SCEX uninstaller. Executing it will remove the SCEX and all associated components from your computer. If the SCEX Loan Server Service is installed, it will stop the service, unregister it with Windows, and then delete it as well. This shortcut is always created.

• SCEX Test Application: A shortcut to run the SCEX test application. As would be expected, it is only created if the SCEX Test Application component is installed.

• SCEX Account Tester: A shortcut to run the SCEX account tester application. This is only created if the SCEX Account Tester Application component is installed.

• SCEX Manual: A link to the pdf manual for the SCEX. Only created if the SCEX Manual component is installed.

Uninstalling the SCEX

To uninstall the SCEX and all of its associated components, you have 2 options:

1. Click on Start ▸ All Programs ▸ Sherman and Associates ▸ SCEX ▸ Uninstall SCEX.
2. Go to Control Panel ▸ Add/Remove Programs ▸ Sherman and Associates ▸ SCEX.

The uninstaller will stop the SCEX Loan Server Service (if running), and remove files and folders as appropriate.

Upgrading the SCEX

If you have already installed a version of the SCEX and wish to upgrade the installation to a newer release, it is recommended that you first uninstall the already installed version first, and then install the newer release. This procedure will ensure that older, out-of-date files are removed and not left behind, which may happen if you simply install the new version in the same location as the older release.

Implementation Overview

Before you can harness the power of the SCEX calculation engine, you first need to be able to call the function(s) contained in the library from your development language.

Functional Interface

To make use of the SCEX, you will need to import one (and only one!) function from the library into your programming environment. Any programming language which can access functions inside shared libraries on your SCEX platform of choice (current platforms supported include win-32, win-64 and linux-x86.64) and has the appropriate data types necessary to call the xmlcalc_ddp() routine should be able to make use of the SCEX.

The only function exported from the SCEX library that is required for implementation (and hence the only one you need to import) is called xmlcalc_ddp(). Here is the function declaration for xmlcalc_ddp(), in Delphi (object pascal, and the language in which the SCEX is written):

function xmlcalc_ddp(
  xmlIn, xmlOut: PAnsiChar;
  lenIn, lenOut: integer;
  var reqIn, reqOut: integer;
  DataDirPath: PAnsiChar
): integer; stdcall;

Note that for the Linux platforms, the stdcall calling convention is replaced with cdecl.

The variable names are found to the left of the :, with the variable type found to its right. This function uses two types of variables: PAnsiChars and integers. Integers are 32-bits in size, and are signed. PAnsiChars are pointers to ANSI character buffers, and in C are expressed as char *. The var modifier indicates that the reqIn and reqOut variables are being passed by reference instead of by value (like the variables xmlIn, xmlOut, lenIn and lenOut are).

Now, let’s see how to go about importing this function in five different languages: Delphi, Visual C++, C#, vb.net, and Java.

Delphi

As the SCEX DLL is written in the Delphi programming environment, it is to be expected that importing the function into a Delphi application is a fairly simple process.

Place the following function declaration in the interface section of a Delphi unit:

function xmlcalc_ddp(
  xmlIn, xmlOut: PAnsiChar;
  lenIn, lenOut: integer;
  var reqIn, reqOut: integer;
  DataDirPath: PAnsiChar
): integer; stdcall; external 'SCEX.DLL'

In this same unit, place the following code in the interface section. Please note that there is no semicolon at the end of this line, and that the SCEX DLL must reside in the same location as your application for this method to work.

Visual C++

To use the xmlcalc_ddp() routine in your Visual C++ application, you will need to dynamically load the library in your code and get the process address for the xmlcalc_ddp() function in that Library. This is best done in your application’s initialization routines, so that once your application has started the function is ready to accept calls. When you terminate the application, then you free up the dynamically loaded library in your code’s termination routine. The relevant Windows API calls which are used in this process are: LoadLibrary(), GetProcAddress(), and FreeLibrary(). For more information, please see the sample code (installed when you install the SCEX Sample Source Code component during the SCEX installation).

C#

To import that xmlcalc_ddp() function into your C# project from scratch, you will need to use System.Runtime.InteropServices. Furthermore, you will also need to be familiar with the StringBuilder class in System.Text, which is the C# equivalent of a character buffer.

For a complete SCEXWrapper class, please see the sample code (installed when you install the SCEX Sample Source Code component during the SCEX installation).

Java

As of release 2018-07-0 of the SCEX, a Java Native Interface function is included in the SCEX library for all supported platforms, and a Java class which implements the JNI call is provided in the sample source code directory java\Scex.java (note that if you did not install the sample source code during installation, then this file will not be present).

To illustrate the use of the Scex.java class, we have also included a simple Java class (Main.java) which creates an instance of the Scex class, sets up an SCEX XML query, and then calls the SCEX and displays the result code and resulting XML.

Note that when using the JNI interface to the SCEX, you must always specify a fully qualified path name for the DTD file, and you must also always specify the DataDirPath attribute for those XML queries which accept one.

If you wish to modify any aspects of the Scex.java file, please carefully read the comments included in it. The JNI function included in the SCEX DLL expects and requires many different facets of class Scex to be as described, and modifying these will result in a non-functional interface. It is our recommendation that Scex.java be left as is unless you are very familiar with the JNI.

Implementing the xmlcalc_ddp() Function

If you are directly calling the xmlcalc_ddp() function exported from the SCEX DLL (instead of using one of the wrapper classes provided with the sample source code), then the next step is to understand the function’s parameters and return results. If you are using one of the provided wrapper classes, then implementation is a bit easier.

Calling xmlcalc_ddp() Directly

If you wish to directly access the xmlcalc_ddp() function, then there are three facets which you must consider: variable declarations, memory allocation and result interpretation.

Variable Declarations

There are four classifications of variables passed to the xmlcalc() routine: pointers to character buffers, allocated buffer sizes, required buffer sizes, and the default data directory path.

The xmlIn and xmlOut variables are pointers to character buffers which your application has allocated (see Memory Allocation, below). The input buffer xmlIn is filled by your application before calling xmlcalc_ddp(), and its contents represent an XML query sent to the SCEX. The result of the query will be returned in the xmlOut buffer, so long as no errors are encountered (see Result Interpretation, below).

The lenIn and lenOut variables are the lengths of the associated buffers. It is critical that your application correctly set the values of these variables to represent the allocated lengths of the input and output buffers, respectively. By informing the SCEX of the size of the input and output buffers, buffer over-runs and the errors that they cause will be non-existent.

The reqIn and reqOut are return parameters used to indicate the necessary size of the input and output buffers. These two result parameters are very useful when you have not allocated enough space for the input or output buffers, as indicated by a given function result code (see Result Interpretation, below).

Finally, the DataDirPath specifies a default data directory for the SCEX to use if one is not supplied in the XML input. Please see documentation on the DataDirPath attribute in the chapter covering Equal Payment Loans for the meaning of this variable.

Memory Allocation

As noted above, providing a buffer into which both the SCEX and your example can copy xml code is of paramount importance. The exact function calls and variable types that you must vary from language to language. Here are a few samples:

• Delphi: To allocate memory for the character buffers which will hold the xmlcalc_ddp() input and output, you can use GetMem(buffer, length), where buffer is of type PAnsiChar (a pointer to character) and length is the requested length of the character buffer, in bytes. Once you are done with the character buffers, make sure to free up the memory which was dynamically allocated using the FreeMem(buffer) procedure, where buffer is again a PChar.

• C, Visual C++: To allocate memory for the input and output buffers in C and Visual C++, use the standard library functions malloc() and free(). See the Visual C++ sample application for an example of how the buffers are dynamically allocated.

• C#, vb.net: Use the StringBuilder class from System.Text. See sample code for an example of its use (and a more user friendly wrappers around xmlcalc()).

Result Interpretation

After calling xmlcalc_ddp(), you should always check the integer return value to ensure that the call finished successfully, and if it did not, what kind of error occurred. Please see Table 3.1 on page 13 for a comprehensive list of result codes accompanied by a description of each.

Optional API Functions

Besides the very important xmlcalc_ddp() routine exported from the SCEX, there are other helpful routines which may be of use during development. Each of these routines is described below.

scex_calc_alloc() and scex_calc_free()

The scex_calc_alloc() routine behaves identically to the xmlcalc_ddp() routine, with the exception that the library function will automatically allocate the necessary output buffer. When first calling this routine, ensure that the output buffer is initialized to NULL and the size of the output buffer is set to zero.

Using this function will prevent calling xmlcalc_ddp() twice when the space allocated by the calling application for the output buffer is too small, and thus can effectively cut the calculation speed in half in these instances.

Since the library is allocating the space necessary for the XML output buffer, the library also must be responsible for freeing this allocated space. Thus, there is the associated scex_calc_free() library function.

Note that many of the sample code wrappers provided have been enhanced to use these new routines to ensure maximum performance.

Here are the function declarations for scex_calc_alloc() and scex_calc_free(), in Delphi (object pascal, and the language in which the SCEX is written):

function scex_calc_alloc( InBuff : PAnsiChar;
  var OutBuff : PAnsiChar;
  InBuffSize : integer;
  var OutBuffSize : integer;
  RootPath : PAnsiChar
): integer; stdcall;

function scex_calc_free( var OutBuff : PAnsiChar;
  var OutBuffSize : integer
): integer; stdcall;

Module Structure

A module is a specific calculation request sent to the SCEX for computation. The core of this manual is a description of each module available in the SCE. This module declaration functions as a switchboard identifier which the SCEX uses to direct the request data to the appropriate colculation.

The SCEX make heavy use of default values in order to precisely represent a loan in question. This maximally scaled-down approach enhances human readability of the XML. Therefore, optional elements and attributes not required for a particular loan should be omitted from the input payload. This best-practice strategy makes understanding a particular loan much easier than having a voluminous and confusing sprawl of irrelevent data.

In general, elements provide structure whereas attributes fine-tune various options available for the element.

XML Request Structure

As a rule of thumb, the root element for an XML request payload is named in (for input) and the name of the module.

<inMODULE Attributes>

   <!-- Data Elements -->
   <Element_Data Attributes>data</Element_Data>

   <!-- Empty Elements -->
   <Element_Empty Attributes/>

   <!-- Parent-Child Structures (usually optional) -->
   <Parent_Element Attributes>
      <Child_Element Attributes>data</Child>
   </Parent_Element>

</inMODULE>

Below is a sample Loan Builder loan request with life protection, illustrating this structure:

<!-- Module Name requesting a Loan Builder calculation -->
<inLOAN_BUILDER>

  <!-- Empty Elements (IntRate, Advance, Payment Stream) with attributes -->
  <EditInterest Date="2024-12-01" AccrualCode="320" IntRate="5.000" />
  <Advance Date="2024-12-01" Amount="10000.00" />
  <PmtStream Begin="2025-01-01" Term="12" />

  <!-- Parent: Loan Protection -->
  <Protection>

    <!-- Both Parent and Child: Life Protection -->
    <Product Code="LI">

      <!-- Child: Birthday of applicant -->
      <Birthday>1966-04-16</Birthday>

    </Product>  
  </Protection>
</inLOAN_BUILDER>  

This common structure facilitates faster understanding of the SCEX modules.

XML Response Structure

Just as all xml module requests are preceded by in, their corresponding response root element name is preceded with an out plus the module name. The basic structure of an SCEX Response is as follows:

<outMODULE Attributes>
  ...
</outMODULE>

Though the SCEX has broad functionality, its current primary usage is in loan computation. Whether that loan module is LOAN_BUILDER, ARM, or any other, the structure of the output is as follows:

<outMODULE Attributes>
   <Results>

      <!-- Success, Failure, Warnings -->
      <Description>*Success or Failure in the calculation request*</Description>
      <XMLDetail>XML Error: An issue that caused the failure.</XMLDetail>
      <XMLDetail>XML Warning: The calculation went through, but unexpected behavior is being reported.</XMLDetail>

      <!-- One or more key numeric results. e.g. Payment -->
      <Payment>326.55</Payment>
   </Results>
</outMODULE>

XML Legend

Color Codes

XML elements and attributes are geometrically color-coded to quickly signal whether or not they are required.

Elements

🟥 Required (Type)
🟦 Optional (Type, Default)

* Asterisk means "multiple elements are allowed".

• "Type" is a top-level explanation of the function of the data element (explained in the first table below).
• "Multiple" means that the element may occur more than once.

Attributes

• 🔸 Required (Format)
• 🔹 Optional (Format, Default)

Types

XML elements and attributes are classified as one of the following types:

Formats

Data sent to the SCEX via element and attribute values is parsed according to the expected format, each of which is described below:

Loan Builder

The Loan Builder module may be used to compute almost any loan imaginable, from the simplest equal payment loan to loans that have exotic and highly customized features.

Sample Request

The following sample illustrates the core structure of a Loan Builder request. It is a request for an equal payment loan with a single advance of $10,000, accruing interest at 5.0%, with a term of 12 months.

<inLOAN_BUILDER>
  <Advance Date="2024-12-01" Amount="10000.00" />
  <EditInterest Date="2024-12-01" AccrualCode="320" IntRate="5.000" />
  <PmtStream Begin="2025-01-01" Term="12" />
</inLOAN_BUILDER>  

Sample Response

The following response is returned from the SCEX when provided with the sample request (above).

<?xml version="1.0" standalone="no" ?>
<!DOCTYPE outLOAN_BUILDER SYSTEM "outLOAN_BUILDER.dtd">
<outLOAN_BUILDER>
   <Results>
      <Description>Successful Calculation</Description>
   </Results>
   <FedBox>
      <AmtFin>10000.00</AmtFin>
      <FinChg>272.60</FinChg>
      <TotPmts>10272.60</TotPmts>
      <RegZAPR Type="Actuarial">4.995</RegZAPR>
   </FedBox>
   <Moneys>
      <Proceeds>10000.00</Proceeds>
      <Principal>10000.00</Principal>
      <Interest>272.60</Interest>
   </Moneys>
   <Accrual>
      <Method>Actual/365 USRule</Method>
      <Days1Pmt DayCount="Actual">31</Days1Pmt>
      <Maturity>2025-12-01</Maturity>
   </Accrual>
   <PmtStream Term="12" Pmt="856.05" Rate="5.000" Begin="2025-01-01" PPY="12"/>
   <AmTable>
      <AmLine Idx="0" Date="2024-12-01" BegBal="0.00" Pmt="0.00" Int="0.00" Prin="-10000.00" UnpaidInt="0.00" EndBal="10000.00"/>
      <AmLine Idx="0" Date="2024-12-01" BegBal="10000.00" Pmt="0.00" Int="0.00" Prin="0.00" UnpaidInt="0.00" EndBal="10000.00"/>
      <AmLine Idx="1" Date="2025-01-01" BegBal="10000.00" Pmt="856.05" Int="42.47" Prin="813.58" UnpaidInt="0.00" EndBal="9186.42"/>
      <AmLine Idx="2" Date="2025-02-01" BegBal="9186.42" Pmt="856.05" Int="39.01" Prin="817.04" UnpaidInt="0.00" EndBal="8369.38"/>
      <AmLine Idx="3" Date="2025-03-01" BegBal="8369.38" Pmt="856.05" Int="32.10" Prin="823.95" UnpaidInt="0.00" EndBal="7545.43"/>
      <AmLine Idx="4" Date="2025-04-01" BegBal="7545.43" Pmt="856.05" Int="32.04" Prin="824.01" UnpaidInt="0.00" EndBal="6721.42"/>
      <AmLine Idx="5" Date="2025-05-01" BegBal="6721.42" Pmt="856.05" Int="27.62" Prin="828.43" UnpaidInt="0.00" EndBal="5892.99"/>
      <AmLine Idx="6" Date="2025-06-01" BegBal="5892.99" Pmt="856.05" Int="25.03" Prin="831.02" UnpaidInt="0.00" EndBal="5061.97"/>
      <AmLine Idx="7" Date="2025-07-01" BegBal="5061.97" Pmt="856.05" Int="20.80" Prin="835.25" UnpaidInt="0.00" EndBal="4226.72"/>
      <AmLine Idx="8" Date="2025-08-01" BegBal="4226.72" Pmt="856.05" Int="17.95" Prin="838.10" UnpaidInt="0.00" EndBal="3388.62"/>
      <AmLine Idx="9" Date="2025-09-01" BegBal="3388.62" Pmt="856.05" Int="14.39" Prin="841.66" UnpaidInt="0.00" EndBal="2546.96"/>
      <AmLine Idx="10" Date="2025-10-01" BegBal="2546.96" Pmt="856.05" Int="10.47" Prin="845.58" UnpaidInt="0.00" EndBal="1701.38"/>
      <AmLine Idx="11" Date="2025-11-01" BegBal="1701.38" Pmt="856.05" Int="7.23" Prin="848.82" UnpaidInt="0.00" EndBal="852.56"/>
      <AmLine Idx="12" Date="2025-12-01" BegBal="852.56" Pmt="856.05" Int="3.50" Prin="852.55" UnpaidInt="0.00" EndBal="0.01"/>
   </AmTable>
</outLOAN_BUILDER>

Loan Builder - Request

Please see the Legend to understand the conventions used to document each element and attribute. Note that for requests, the XML elements are documented in alphabetical order by parent element.

🟥 <inLOAN_BUILDER>

This is the root element of the request, and is required. This contains child elements which specify the particulars of the requested loan.

Attributes: 🔹Country

🔹 Country

This attribute allows the calling application to specify a two (2) character or three (3) digit country code. If none is provided, then a default value of US will be used. Please see this table of supported countries and their associated codes.

Currently, the country code is used to determine the default value of the Code attribute of the <APR> element.

🟥 <Advance>[]

Cash advances to the customer are specified by using the following attributes of this empty element.

Attributes: 🔹Amount, 🔹Compute, 🔸Date, 🔹ExtraDays, 🔹NewPmt, 🔹Position

🔹 Amount

The proceeds to be advanced to the borrower is defined using this attribute. If the calling application requests that the advance be computed (see the Compute attribute below), then the value of this attribute will be added to the computed advance amount, which can be useful in multiple advance loans.

🔹 Compute

Some applications like to provide useful what-if calculations, such as, "how much can I afford to borrow given a specified loan term, interest rate, and payment stream?" Here at Sherman and Associates, we call this a Roll to Advance calculation.

If the value of this attribute is true, then the calling application is requesting that the SCEX calculate one or more advances given a specified term, interest rate, and payment stream. With this in mind, all <PmtStream> elements (which define the specified payment streams in the loan) may not have a PmtType of CalcPmt. Usually, all payment streams will be defined using a PmtType of FixedPmt.

We have provided several XML samples which illustrate various Roll to Advance calculations in the /samples directory included with the SCEX installer, for your reference.

🔸 Date

This attribute holds the XML date on which the advance is made. All dates must be in the form of YYYY-MM-DD, and be 10 characters long. Hence, an advance date of January 2, 2008 would be specified as Date="2008-01-02".

🔹 ExtraDays

Increase or decrease the number of days between this event and the next event by the value of this attribute. e.g. 1 will be considered one more day of interest.

🔹 NewPmt

If the payment should change to reflect a new advance, set this attribute to true; otherwise, the payment will not change after this event. If only one <Advance> element is being used, then this attribute should be omitted altogether.

🔹 Position

If an advance and a payment fall on the same day, the value of this attribute determines which event occurs first in the amortization schedule. Note that the first advance of every loan is required to occur before the first scheduled payment.

• BeforePmt - When the advance occurs on the same date as a payment, the advance is amortized before the payment.
• AfterPmt - When the advance occurs on the same date as a payment, the payment is amortized before the advance.

🟦 <APR>

Settings related to the computed effective rate returned by the SCEX (most commonly, the Regulation Z APR in the United States of America) are contained in the attributes of this otherwise empty element.

Attributes: 🔹Code, 🔹Decimals, 🔹MAPR_Max, 🔹Max, 🔹SinglePayFraction, 🔹StrictTime, 🔹UseMAPR

🔹 Code

The method of APR computation is defined by this attribute. If this attribute is not set up, the default method depends upon the value of the Country attribute. For the United States of America, the default value is 100 (Actuarial). For a country in the European Union, the default value is 50 (European Union APR). For Canada, the default value is 60.

🔹 Decimals

The number of decimal places of accuracy for the disclosed APR is determined by this attribute. The default value of this attribute is 3.

🔹 MAPR_Max

If you are computing the Military APR (see UseMAPR below) and wish to override the default maximum APR value of 36%, then specify the desired maximum as the value of this attribute.

🔹 Max

If the calling application wants the SCE to check the computed APR against a specified maximum APR, then specify the maximum APR using this attribute. If a maximum is specified, then this maximum will be included in the <RegZAPR> response element in the Max attribute, and a MaxExceeded attribute will also be returned to inform the calling application whether or not the specified maximum was exceeded.

🔹 SinglePayFraction

This attribute only applies to single advance, single payment transactions of term less than one year. For these loans, when the term of the loan is a number of months, Appendix J allows for the term of the loan to be expressed as either a number of months over twelve, or the number of actual 24-hour days in the loan over 365. For the former, use InMonths. For the latter, use InDays.

🔹 StrictTime

When monthly payments are intended for the 29th or 30th of the month, how should the number of unit periods and fraction be calculated in February, when the day of the payment cannot be the intended day? (e.g. A non-leap year February where payments are meant for the 29th, but end up on the 28th). StrictTime acknowledges and disambiguates the calculation. Regular payments generally hold the fraction of a unit period constant, based on the date of the first payment. The SCEX allows for a constant fraction of a unit period or a strict time accounting, acknowledging that in February, the fraction of a unit period changes.

When the value of this attribute is true, the SCEX will calculate the fraction of a unit period strictly according to the rules of Appendix J of Regulation Z. A value of false instructs the SCEX to keep the fraction of a unit period constant, equal to the fraction obtained by the time calculated from the date of the first payment to the transaction date.

🔹 UseMAPR

If this attribute is set to a value of true, then the SCEX will compute the Military APR in addition to the Regulation Z APR. The <MAPR> element will be included in the XML loan response.

🟦 <BalAdj>[]

The balance that evolves with the amortizing of a loan may be adjusted to either a specific amount called a Target, or by a specific an amount called an Adjust. This element helps support open ended lending products, such as HELOCs.

Attributes: 🔹Adjust, 🔸Date, 🔹NewPmt, 🔹Target

🔹 Adjust

The value of the Adjust attribute instructs Loan Builder to adjust the balance by the amount defined, arriving at a Target equal to the sum of the current balance and the Adjust value. Either a Target or an Adjust must be defined, but not both.

🔸 Date

The Date attribute for the <BalAdj> element is used to define the date on which the adjustment to the loan balance is expected to occur. When the date occurs on the same day as a payment, the payment occurs before the balance adjusts.

Because one often frames the balance adjusting ”after the 12^th payment”, for instance, a date masking is provided to accomplish this objective. So, rather than defining the date in the usual YYYY-MM-DD date format, the date can be defined in a nnnn-00-00 format, where ”nnnn” is the left zero-filled payment index after which the adjustment occurs.

So, if we know the 12^th payment occurs on February 1st, 2025, the following balance adjustments are equivalent:

<BalAdj Date="2025-02-01" Target="5000" />
<BalAdj Date="0012-00-00" Target="5000" />

🔹 NewPmt

If the payment should change to reflect the balance adjustment, set this attribute to true; otherwise, the payment will not change after this event.

🔹 Target

The value of the Target attribute instructs the SCE to adjust the balance to the target amount, calculating the necessary Adjust amount to meet that objective. Either a Target or an Adjust must be defined, but not both.

🟦 <BusinessRules>

Certain loan calculation business rules may be configured using the attributes of this otherwise empty element.

Attributes: 🔹AmError, 🔹AmortizeOnly, 🔹CanSkipFirst, 🔹CanSkipLast, 🔹ClosedFormEqn, 🔹LeapYearRound, 🔹MinFinChg, 🔹MinIntChg, 🔹MYED, 🔹PmtAccrualCode, 🔹OddFirstPmt, 🔹ProtMandatory, 🔹UsRuleAprException, 🔹YieldPPY, 🔹ZeroInterestRule

🔹 AmError

When amortizing a loan, often times there is a non-zero ending balance due to rounding. This attribute determines what to do (if anything) with a non-zero ending balance. This non-zero balance is referred to as the amortization error.

• Allow - Do not do anything with the non-zero ending balance.
• AdjPmt - Adjust the final payment to achieve perfect amortization, which will then result in an ending balance of zero.
• AdjPrin - Adjust the final principal reduction amount to achieve perfect amortization, which will then result in an ending balance of zero.
• AdjInt - Adjust the final interest reduction amount to achieve perfect amortization, which will then result in an ending balance of zero.

Note that using AdjPrin or AdjInt will cause the final payment to not equal the sum of the principal reduction amount and amount to interest in the amortization schedule.

🔹 AmortizeOnly

If the calling application sets the value of this attribute to true, then instead of computing a loan with payments that best amortize the principal balance to zero, the Loan Builder module is instructed to simply amortize the specified loan (all advances and payments specified by the calling application) and return the ending balance.

To use this functionality, there are a few requirements that must be met:

• All specified payment streams must have a PmtType of other than CalcPmt. In AmortizeOnly mode, the Loan Builder will not compute "regular" principal and interest payments.
• No protection products may be requested.
• All advances must be specified, and not computed.
• AmError must be set to Allow.

Furthermore, the output for an AmortizeOnly="true" Loan Builder request will omit the <FedBox> and <Moneys> output elements.

🔹 CanSkipFirst

Set this attribute to true to allow the first payment of a loan to be skipped. The default value of false does not allow a skipped first payment.

🔹 CanSkipLast

Set this attribute to true to allow the last payment of a loan to be skipped. The default value of false does not allow a skipped final payment.

🔹 ClosedFormEqn

When searching for the payment that best amortizes the loan to zero, this setting determines whether or not interest is rounded during the payment search algorithm. The default value of true indicates that the closed form equation should be matched, and interest will be left unrounded during the payment search algorithm. Setting this attribute value to false will cause interest to be rounded during the payment search algorithm.

🔹 LeapYearRound

If the value of this attribute is true and one of the actual/actual interest accrual calendars (including Midnight366) is used in the requested loan, then the interest accrued on a 365 days basis is rounded separately from the interest accrued on a 366 days basis. Note that this option is encountered very rarely in the marketplace.

If the value of this attribute is false, then interest computed on a 365 day basis will be added to the interest computed on a 366 day basis, and then rounded.

🔹 MinFinChg

This attribute allows the calling application to specify a minimum allowed finance charge for the loan. If a value greater than zero is specified, then the loan will be computed in the normal manner, along with the finance charge. If the computed finance charge falls below the specified minimum, then the final payment's interest charge will be adjusted to meet the specified minimum.

Note that the minimum interest charge is checked before the minimum finance charge. If the loan triggered a minimum finance charge adjustment, then the amount of this adjustment will be disclosed in the <MinFinChgAdj> child element of the <Moneys> response element.

Note that since the minimum finance charge check is done after the loan payment and protection calculations have been completed, certain protection products whose calculations may vary due to a modified final payment will not reflect any minimum finance charge adjustments made to the final payment.

🔹 MinIntChg

This attribute allows the calling application to specify a minimum allowed interest charge for the loan. If a value greater than zero is specified, then the loan will be computed in the normal manner, along with the interest charge. If the computed interest charge falls below the specified minimum, then the final payment's interest charge will be adjusted to meet the specified minimum.

Note that the minimum interest charge is checked before the minimum finance charge. If the loan triggered a minimum interest charge adjustment, then the amount of this adjustment will be disclosed in the <MinIntChgAdj> child element of the <Moneys> response element.

Note that since the minimum interest charge check is done after the loan payment and protection calculations have been completed, certain protection products whose calculations may vary due to a modified final payment will not reflect any minimum interest charge adjustments made to the final payment.

🔹 MYED

The MYED attribute represents the Mortgage Year End Date when computing an annual rest loan, a loan which is commonly encountered in the United Kingdom. If you do not need to compute an annual rest loan, then this attribute need not be included in the request XML.

If included in the XML, then the value of the attribute must be in the format of "MM-DD" where MM is a valid month number from 1 to 12, and DD is a valid day number in the month specified. The month and day specified is the annual date on which escrowed payments and interest are applied to the outstanding principal balance. When the MYED is specified, you must also specify a <PmtStream> element with a PmtType attribute value of PmtEsc, which indicates an escrowed payment.

🔹 OddFirstPmt

If the first payment should be adjusted (up or down) due to odd days interest in the same manner that interest is accruing in the loan, then set the value of this attribute to true. A value of OnlyPositive instructs the SCE to only adjust the first payment due to odd days if there are positive odd days. Finally, a value of false instructs the SCE to not adjust the first payment using this method.

Note that you cannot specify an odd first payment using this attribute and include <OddDaysPrepaid> in the same request.

🔹 PmtAccrualCode

In rare instances, the calculated payment for a given loan is based upon a different accrual calendar than the one used to amortize interest in the amortization schedule. This is most commonly encountered when a system is not able to compute the ‘best’ payment, and instead uses a simpler accrual calendar with a closed form equation (such as unit period simple). An estimated payment is computed, then used in the amortization schedule where interest is accrued on a different calendar. Note that this will almost always generate an ending balance of greater magnitude that the ‘correct’ payment, unless the AmError attribute is used to adjust the final payment.

A value of default means that the payment will be computed using the same accrual calendar as interest. Any other value will cause the computed payment to be calculated using the accrual code specified.

🔹 ProtMandatory

If the value of this attribute is set to true, then protection premiums/fees will be considered to be a part of the Finance Charge, and thus affect the Regulation Z APR.

🔹 UsRuleAprException

The US Rule APR Exception is an option used by some financial institutions that accrue interest in a US Rule manner, and also disclose the US Rule APR. If this attribute is omitted or set to false, the US Rule APR will always be computed.

If the value of this attribute is set to true and the following conditions are met: (i) interest is accrued via a US Rule method, (ii) A US Rule APR method matching the accrual method has been specified, (iii) the Regulation Z Finance Charge is equal to the interest charge, and (iv) there is only a single <EditInterest> event, then the US Rule APR will be disclosed as the interest rate.

🔹 YieldPPY

Canadian mortgages may compute periodic interest using a fractional power of a periodic yield. If set to a value other than 0, this value determines the period. Please contact us for further information if you support mortgage calculations in Canada. Note that when using this attribute with a value other than zero, the calling application must include an odd days prepaid fee in the request.

🔹 ZeroInterestRule

If the value of this attribute is true and (i) the interest rate for the entire term of the loan is 0%, or (ii) the computed interest charge for the loan is less than zero, then the interest charge will be set to a value of zero, and the Regulation Z Finance Charge will be adjusted in an identical manner.

Note that setting the value of this attribute to true will likely cause the sum of the principal and interest to no longer equal the total of payments (similarly for the Amount Financed and Finance Charge). Sherman and Associates do not recommend that you set the value of this attribute to true before consulting with your legal counsel in regards to these and other unforseen consequences.

Lastly, all payment rounding is forced to be rounded down to the nearest penny. This adjustment ensures that the sum of payments never exceeds the Principal Balance of the loan.

🟦 <Capitalize>[]

Some loans require interest to be capitalized on specific dates, irrespective of any other considerations. For these events, use the <Capitalize> element.

Attributes: 🔹AllowFeb29, 🔸Date, 🔹Holidays, 🔹PPY, 🔹SemimonthlyDay, 🔹Term, 🔹Weekends

🔹 AllowFeb29

This attribute is used when generating event dates in a capitalization stream (if any) beyond the specified Date date of the <Capitalize> element. If the value of this attribute is true, then February 29th is an allowed date.

On the other hand, if the value of this attribute is set to false and a computed date in the given capitalization stream is scheduled to fall on February 29th, then the scheduled date will be altered in one of the following manners:

If the number of payments per year is 1, 2, 4, 6, 12, or 24 then the scheduled date of February 29 will be moved back one day to February 28. This is the only date that will be adjusted.

If the number of payments per year is 26 or 52 then the scheduled date of February 29 will be moved forward one day to March 1, and all subsequent dates will be a multiple of 7 or 14 days from this date (depending upon the specified payment frequency).

🔸 Date

The Date attribute for the <Capitalize> element is used to specify the date on which to capitalize interest. (For a stream of Capitalize events, see the Term attribute.) As an example, if interest is to be capitalized on Feb. 1, 2008, the attribute should be specified as Date="2008-02-01".

🔹 Holidays

If capitalization dates (including the specified start date) are not allowed to fall on specified holidays (see the <Holiday> element for more information on how to specify holidays), then set the value of this field to something other than Ignore. The meaning of the other two values are defined below:

• Ignore - No holidays will be considered.
• Prev - The date will be moved to the day before the holiday.
• Next - The date will be moved to the Monday after the holiday.

Note that two other <Capitalize> element attributes can cause the computed dates to be adjusted - AllowFeb29 and Weekends. The rules for how these three fields interact are described below in detail.

For every date required in our payment stream, the SCEX goes through the following steps:

1. Generate the next date in our date stream, called the target date.
2. If February 29th is not allowed and if the target date is 2/29, then adjust the target date forward or backward one day based upon the date generation frequency. If the frequency is a monthly multiple, then the target date is moved backward one day to 2/28. Weekly and biweekly frequencies move the target date forward one day to 3/1.
3. If weekend dates are not allowed (e.g. the Weekends attribute holds a value other than Ignore) and the target date falls on a Saturday or Sunday:
   • (a) then adjust the target date according to the attribute value.
   • (b) if February 29th is not allowed and if the target date is 2/29, then adjust the target date in the same direction as in 3(a) above.
4. If holidays are not allowed (e.g. the Holidays attribute holds a value other than Ignore) and the target date falls on a specified holiday:
   • (a) then adjust the target date according to the Holidays attribute value.
   • (b) If weekend dates are not allowed (e.g. the Weekends attribute holds a value other than Ignore) and the target date falls on a Saturday or Sunday, then adjust the target date in the same direction as in 4(a) above.
   • (c) if February 29th is not allowed and if the target date is 2/29, then adjust the target date in the same direction as in 4(a) above.
   • (d) Step 4 is repeated until the target date is not adjusted.

🔹 PPY

PPY is an abbreviation for payments per year, and as one might surmise, determines the capitalization frequency for the loan. If only one capitalization event occurs or the stream of capitilization events are monthly, this attribute may be ignored.

🔹 SemimonthlyDay

When specifying a semimonthly stream, the day number on which the first capitalization event occurs determines the day number for all of the following odd numbered events. If you omit this attribute or specify a value of 0, then the even numbered events will be generated using the default method within the SCEX.

If you wish to specify the day number on which even numbered events fall (overriding the default method used in the SCEX), then set the value of this attribute to the desired day number. Setting the value of this attribute to 31 will cause all even events to fall on the last day of the month.

As an example, if you want to specify a semi-monthly capitalization stream beginning on January 1, 2014 with events that fall on the 1st and 15th of each month for 24 events, the element should look something like this:

<Capitalize Date="2014-01-01" Term="24" PPY="24" SemimonthlyDay="15" />

🔹 Term

The Term attribute indicates the the number of capitalization events to be made at the specified frequency (see PPY above). The default value is 1. If only one capitalization event is to be used, ignore this attribute.

🔹 Weekends

If capitalization stream dates (including the specified start date) are not allowed to fall on a Saturday or Sunday, then set the value of this field to something other than Ignore. The meaning of the other three values are defined below:

• Prev - The date will be moved to the Friday before the computed weekend date.
• Near - The date will be moved to the Friday before the computed weekend date if the computed weekend date falls on a Saturday, otherwise it will be moved to the Monday after.
• Next - The date will be moved to the Monday after the computed weekend date.

Note that two other attributes can cause the computed dates to be adjusted - AllowFeb29 and Holidays. For a complete description of how these three fields work together, please see the documentation for the Holidays attribute.

🟦 <Construction>

This element is used when a loan features a construction period, during which time interest only payments are made by the borrower. Construction periods always begin on the date of the first advance.

Generally speaking, there are two methods used to disclose construction loans. The first method computes the total estimated interest due during the construction period, and treats it as an unfinanced prepaid fee. The second method discloses discrete interest only payments in the amortization schedule during the construction period.

To emulate the first method, simply include the <Construction> element and ensure that no payment events are set up to occur during the construction period. The construction interest will be computed and returned in the <ConInterest> response element with the IsPrepaid field set to true.

To emulate the second method, set up an interest only payment stream which begins during the construction period, with the final interest only payment occurring on the construction period's ending date. The interest only payments will then appear in the resulting amortization schedule, and the total construction interest will be returned in the <ConInterest> response element with the IsPrepaid field set to false.

Attributes: 🔸EndDate, 🔹HalfCommitment

🔸 EndDate

The date on which the construction period terminates.

All dates must be in the form of YYYY-MM-DD, and be 10 characters long. Hence, to end the construction period on July 4, 2011, the attribute would be specified as EndDate="2011-07-04". If the calling application sets up discrete interest only payments during the construction period, then the EndDate may also be specified as occurring on a given payment number nnnn as EndDate="nnnn-00-00".

🔹 HalfCommitment

During the term of the construction loan, the estimated interest for disclosure purposes may be either computed on the full or half commitment amounts. By setting this attribute to true, interest will be estimated using half of the initial commitment amount (i.e. the principal balance). The default value of false will cause interest to be estimated using the entire initial commitment amount.

🟦 <EditInterest>[]

This element is used to specify how interest is calculated. The element itself is empty, with all data for interest accrual specified in the following attributes.

Attributes: 🔹AccrualCode, 🔹Capitalize, 🔹Date, 🔹ExtraDays, 🔹IntRate, 🔹IntRound, 🔹NewPmt, 🔹PmtRound

🔹 AccrualCode

The method of interest accrual is defined by this attribute. default means one of two things: (i) if no accrual method has beend defined at all, then use the system default of 201, or (ii) if an accrual code has been previously defined, then continue to use that method. Please see the Loan Builder Accrual Codes and Descriptions table for the meanings of each code.

Add-on interest methods 401..406 have restrictions that apply. Only equal payment loans with one <EditInterest> element may use add-on interest. In addition, construction loans may not be used with add-on interest. Protection products (if any) must be single premium.

🔹 Capitalize

If interest due is to be added to principal (capitalized) on the specified Date, set this attribute’s value to true.

🔹 Date

Set the date of this event. If the date is omitted, the system will use the date of the earliest advance. If an advance has not yet been specified, the system will return an error message.

All dates must be in the form of YYYY-MM-DD, and be 10 characters long. Hence, to change the interest rate on January 2, 2008, the attribute would be specified as Date="2008-01-02".

However, to provide power and flexibility to the calling application, the SCEX will also understand Date values in the following formats:

• nnnn-00-00 - If you wish to change an interest accrual parameter on the date of a specific payment number (n), use a value of nnnn-00-00. Thus, an attribute value of 0012-00-00 instructs the engine to set the date of this event equal to that of the 12’th payment. A value of 0000-00-00 will set the date of the event equal to the date of the first advance.

🔹 ExtraDays (integer, 0)

Increase or decrease the number of days between this event and the next event by the value of this attribute. e.g. 1 will be considered one more day of interest.

🔹 IntRate

Defines the interest rate that applies at and beyond this event. If no IntRate is specified, the previously defined interest rate is used. A value of zero will be used if no previous IntRate has been defined.

🔹 IntRound

Defines how the computed interest amount is to be rounded.

🔹 NewPmt

If the payment should change to reflect a new interest rate, set this attribute to true; otherwise, the payment will not change after this event. If only one <EditInterest> element is being used, then this attribute should be omitted altogether.

🔹 PmtRound

This attribute allows the calling application to specify a payment rounding option which will override the value found in the setup file. If not specified, then the value of default will be used. The linked table lists all valid payment rounding codes available.

• default - Use method specified in setup file
• nearest - Round computed payment to the nearest penny, using 5/4 rounding. e.g. 300.242 = 300.24, 300.245 = 300.25.
• up - Round computed payment up to the next penny. e.g. 300.241 = 300.25.
• down - Round computed payment down to the previous penny. e.g. 300.249 = 300.24.
• best - Once the unrounded payment has been computed, amortize the loan using the rounded down and rounded up payment, and then return the payment which amortizes the loan’s ending balance closest to zero.

Note: If the ZeroInterestRule attribute of the <BusinessRules> element is set to true and all interest rates are zero, payments are forced to be rounded down. This rule ensures the total of payments never exceeds the amounts of the loan to pay off (the principal balance).

🟦 <EditInterest>[]→<Tier>[]

To compute interest using a split rate method, where different rates are applied to different parts of the balance, the calling application will need to specify a <Tier> element with its associated Rate and Ceiling attributes. Note that the IntRate which is used above the final Ceiling is the one specified in the <EditInterest> element. Furthermore, the <Tier> elements must be ordered in ascending order based upon the Ceiling amount.

As an example, assume that the calling application needs to charge 20% on the first $100, 15% up to $250, and 10% for the remaining balance. The XML needed to implement this split rate structure is:

<EditInterest Date="2020-04-01" IntRate="10.000" AccrualCode="201">
  <Tier Rate="20.000" Ceiling="100" />
  <Tier Rate="15.000" Ceiling="250" />
</EditInterest>

Attributes: 🔸Ceiling, 🔸Rate

🔸 Ceiling

Defines the upper bound of the principal to which the specified split rate tier will apply.

🔸 Rate

Defines the interest rate that applies to this split rate tier.

🟦 <EditOutput>

Changes to the presentation of the output data are contained in the attributes of this otherwise empty element.

Attributes: 🔹EarlyPayoffDate, 🔹KeepSlush, 🔹Merge, 🔹PmtDollarRound, 🔹ShowAmTable, 🔹ShowFees, 🔹ShowGrandTot, 🔹ShowSubTot, 🔹ShowTap, 🔹ShowType, 🔹TagPmts

🔹 EarlyPayoffDate

Specifying an EarlyPayoffDate results in a two-step computation: compute the loan completely ignoring the EarlyPayoffDate, then eliminate all events subsequent to the early payoff date and payoff the loan on that early payoff date. One common use of this attribute is to generate computed regular payments based upon a longer amortization term, with a final balloon payment made on the early payoff date (much like the <inBALLOON_SPECIFY_AMORT> query).

• omitted - If EarlyPayoffDate is omitted, no early payoff will be computed.
• YYYY-MM-DD - If an early payoff date is in the format of a valid XML date (i.e. YYYY-MM-DD), the loan will be paid off on the specified date.
• nnnn-00-00 - If the early payoff date is in the format of nnnn-00-00, then the loan will be paid off by the n'th payment.

🔹 KeepSlush

Rounding interest each period numerically eliminates values beyond two decimal places. This amount is referred to as slush. To keep this amount and add it to next period’s unrounded interest, set KeepSlush to true.

🔹 Merge

If the value of this attribute is set to true, then payment elements will be merged together whenever possible. For example, if one event is of type CalcPmt, and another on the same day is PayPrin, then this attribute determines whether or not these two events will be combined into a single payment event or left as separate and distinct events.

🔹 PmtDollarRound

Payments are normally rounded to the penny, according to the method specified by the PmtRound attribute of the <EditInterest> element. If the payment should be rounded to the dollar instead of the penny, then set the value of this attribute to true. Note that for some loans (such as those with longer terms or relatively small proceeds), rounding the payment up or to the nearest dollar may require a shortened loan term to prevent one or more negative payments at the end of the loan.

🔹 ShowAmTable

To suppress the entire amortization schedule from the response, set this attribute value to false; otherwise, the amortization schedule will be returned.

🔹 ShowFees

If this attribute is set to false, then fees will not explicitly appear in the amortization schedule, unless they do not occur on the date of an advance or the date of a payment. They will also not be individually listed under the <Moneys> element of the outputs.

A value of true means that all fees will be explicitly accounted for, both in the <Moneys> element as child elements and in the amortization table. The Type attribute will have the name of the fee as its value.

🔹 ShowGrandTot

To show the amortization schedule grand totals in the response, set this attribute value to true; otherwise, the grand totals will not be returned.

🔹 ShowSubTot

To show the amortization schedule annual subtotals in the response, set this attribute to true; otherwise, annual subtotals will not be returned.

🔹 ShowTap

If not specified, the default value of this attribute is determined by the Country specified. If the Country is GB (United Kingdom), then the default value is true. All other country values will default this attribute to false.

The value of this attribute determines if the total amount payable output element (i.e. <TAP>) will be computed and disclosed in the response. This quantity is broadly defined as the total of payments plus fees that do not enter into the amortization table in any way.

🔹 ShowType

Each line of the amortization schedule is characterized by a type, which describes the particular amortization event. An EditInterest event is different from a FixedPmt event, for example. Set this attribute to true to report the Type of each amortization event. A value of false will suppress output of the Type attribute in the amortization schedule.

🔹 TagPmts

If the value of this attribute is set to true, then each <PmtStream> result element will include an Idx attribute which identifies the input payment element which gave rise to it. If this attribute is set to true, then the Merge attribute must be set to false. If both are set to true, then an error will be returned.

🟦 <EndBal>

When computing a loan, the usual intention is to compute a payment which produces an ending balance of zero at the end of the repayment schedule. However, in some international markets (such as Australia / New Zealand), some loans are computed with a specified ending balance greater than zero. To support these types of loans, the <EndBal> element is provided.

If omitted, the desired ending balance at the end of the repayment schedule is defaulted to 0. To specify a desired ending balance greater than zero, simply specify the desired ending balance as an appropriately formatted currency value as the element’s value.

For example, if the desired ending balance is $50,000.00, then you would include <EndBal>50000.00</EndBal> in your request.

Note that if an ending balance greater than zero has been specified, then no protection products are allowed to be written with the loan, and the APR (and MAPR if requested) are not computed.

Attributes: None

🟦 <Fee>[]

Single occurrence and recurring fees are passed to the engine using the attributes of this empty element.

Attributes: 🔹AddToFinChg, 🔹AddToPrin, 🔹Adjust, 🔹AllowFeb29, 🔸Amount, 🔹Blended, 🔹CalcType, 🔹Date, 🔹EqualServChg, 🔹Holidays, 🔹LastDay, 🔹MAPR, 🔹Max, 🔹Min, 🔹Name, 🔹Position, 🔹PPY, 🔹Round, 🔹RoundBasis, 🔹SemimonthlyDay, 🔹ServChgType, 🔹Term, 🔹Weekends

🔹 AddToFinChg

If this fee should be included in the Reg. Z Finance Charge (and hence, affect the APR), then set this attribute to true. The default value of false indicates that the fee does not affect the Finance Charge nor APR.

🔹 AddToPrin

If this fee should be added to the principal balance (e.g. the fee is financed along with the advance(s)), then set this attribute to true. If set to false, then the fee is paid up front out of the borrower’s pocket.

🔹 Adjust

The optional Adjust attribute allows the calling application to increase or decrease the base amount on which a fee is calculated. If a negative value is specified and this adjustment would produce a negative base amount, then a value of zero is returned for the given fee. This attribute has no effect on fees with a CalcType of Dollar.

As an example, in Tennessee you may need to define a financed, non-APR affecting fee to be computed by decreasing the amount financed by $2,000, and then multiplying this reduced amount by 0.115. The way to accomplish this in the SCEX is as follows:

<Fee Name="TN_Fee" CalcType="OnAmtFin" Adjust="-2000" Amount="0.115"
  AddToPrin="true" AddToFinChg="false" />

🔹 AllowFeb29

This attribute is used when generating fee dates in a fee stream (if any) beyond the specified Date date of the <Fee> element. If the value of this attribute is true, then February 29th is an allowed fee date.

On the other hand, if the value of this attribute is set to false and a computed date in the given fee stream is scheduled to fall on February 29th, then the scheduled fee date will be altered in one of the following manners:

• If the number of payments per year is 1, 2, 4, 6, 12, or 24 then the scheduled fee date of February 29 will be moved back one day to February 28. This is the only date that will be adjusted.
• If the number of payments per year is 26 or 52 then the scheduled fee date of February 29 will be moved forward one day to March 1, and all subsequent fee dates will be a multiple of 7 or 14 days from this date (depending upon the specified payment frequency).

🔸 Amount

How this attribute is interpreted depends upon the CalcType attribute.

🔹 Blended

The Blended attribute determines how the SCEX will include the fee with a payment or advance.

• true in an advance tells the SCEX that the amount of the advance already includes the fee. false means to add the fee on top of the existing advance.
• true in a payment means that the payment has the fee already included in it. false means the fee is added on top of the payment.

🔹 CalcType

This attribute specifies how the fee is to be computed, as described in the table below:

• Dollar - The Amount attribute is understood as a flat currency amount.
• OnProceeds - The Amount attribute is understood as a percentage value, to be applied to the loan’s proceeds, defined as the sum of advances. An Amount of 0.25 would represent a fee of 0.25% of the total proceeds.
• OnPrincipal - The Amount attribute is understood as a percentage value, to be applied to the loan’s principal balance. An Amount of 0.125 would represent a fee of 0.125% of the principal balance.
• OnAmtFin - The Amount attribute is understood as a percentage value, to be applied to the loan’s Regulation Z Amount Financed. An Amount of 0.33 would represent a fee of 0.33% of the amount financed.
• OnBalance - The Amount attribute is understood as an annual percentage value, to be applied to the current balance of the loan when the fee is assessed, and accrued using the interest accrual calendar in effect. An Amount of 12.0 would represent a fee accrued at an annual rate of 12.0% of the current balance.
• OnBalanceFlat - The Amount attribute is understood as a flat percentage value, to be applied to the current balance of the loan when the fee is assessed. An Amount of 1.0 would represent a fee of 1.0% of the current balance.

🔹 Date

The date on which a fee occurs. If this element defines a stream of more than one fee, then this attribute defines the date on which the first fee occurs. If the date is the same as an advance or payment, the fee is loaded into the advance or payment event; otherwise, the fee is a stand-alone event. All dates must be in the form of YYYY-MM-DD, and be 10 characters long. Hence, a fee date of January 2, 2008 would be specified as Date="2008-01-02".

A special format is accepted for annual fees (PPY value of 1) paid on a specific calendar month of the year. Using 0000-MM-00 as a value for Date instructs the SCE to pay the fee on the MM payment of the payment stream. For example, 0000-06-00 instructs the system to pay this fee on June Payments.

If the Date attribute is not specified, then it will default to the earliest specified Advance Date.

🔹 EqualServChg

When a fee is set up as a service charge of type ByTerm (see ServChgType), this attribute determines if all the service charge fee payments should be forced to be equal (a value of true), or if the final service charge fee payment can be different from the others due to rounding (a value of false).

🔹 Holidays

If capitalization dates (including the specified start date) are not allowed to fall on specified holidays (see the <Holiday> element for more information on how to specify holidays), then set the value of this field to something other than Ignore. The meaning of the other two values are defined below:

• Ignore - No holidays will be considered.
• Prev - The date will be moved to the day before the holiday.
• Next - The date will be moved to the Monday after the holiday.

Note that two other element attributes can cause the computed dates to be adjusted - AllowFeb29 and Weekends. The rules for how these three fields interact are described below in detail.

For every date required in our payment stream, the SCE goes through the following steps:

1. Generate the next date in our date stream, called the target date.
2. If February 29th is not allowed and if the target date is 2/29, then adjust the target date forward or backward one day based upon the date generation frequency. If the frequency is a monthly multiple, then the target date is moved backward one day to 2/28. Weekly and biweekly frequencies move the target date forward one day to 3/1.
3. If weekend dates are not allowed (e.g. the Weekends attribute holds a value other than Ignore) and the target date falls on a Saturday or Sunday:

• (a) then adjust the target date according to the attribute value.
• (b) if February 29th is not allowed and if the target date is 2/29, then adjust the target date in the same direction as in 3(a) above.

4. If holidays are not allowed (e.g. the Holidays attribute holds a value other than Ignore) and the target date falls on a specified holiday:

• (a) then adjust the target date according to the Holidays attribute value.
• (b) If weekend dates are not allowed (e.g. the Weekends attribute holds a value other than Ignore) and the target date falls on a Saturday or Sunday, then adjust the target date in the same direction as in 4(a) above.
• (c) if February 29th is not allowed and if the target date is 2/29, then adjust the target date in the same direction as in 4(a) above.
• (d) Step 4 is repeated until the target date is not adjusted.

🔹 IsLoanCost

When requesting the new TILA RESPA outputs (via the <TILARESPA2015> element), the SCEX needs to know which fees need to be considered "borrower paid loan costs", as defined in the rule. Please note that if the fee is paid by a lender or other third party, then the fee does not affect the loan calculation and should not be sent to the SCEX. If it is sent, then the value of this attribute should be set to false.

🔹 LastDay

This attribute is used to resolve ambiguities in subsequent fee dates when the Date falls on the last day of a month with fewer than 31 days. If the value of the Date attribute is not a valid date, then the value of this attribute is ignored. If the value of the Term attribute is 1, then the value of this attribute is ignored.

Set this attribute’s value to true if the intent was to make subsequent fees occur on the last day of the month. A value of false indicates that subsequent fee dates will fall on the day number specified by the Date date.

As an example, if the calling application specifies a Date of 2010-02-28, then subsequent fee dates for a monthly fee frequency will be:

• on the 28th of each subsequent month if LastDay="false".
• on the last day of each subsequent month if LastDay="true".

🔹 MAPR

If you wish to compute the Military APR, then certain fees may not be considered Regulation Z APR affecting fees, but are considered Military APR affecting fees. In this case, you will need to set the value of this attribute to true.

Fees which are added to the finance charge (see AddToFinChg) are always considered MAPR fees, regardless of the stated value of this attribute.

Note that debt protection products are automatically included in the calculation of the Military APR, no matter what method is used for payment (e.g. single premium vs. monthly outstanding balance).

🔹 Max

If a maximum value for the fee is specified and is greater than zero, then if the computed fee exceeds this maximum value, then the maximum value will be used instead. If no maximum value is specified or is set to a value of zero, then no maximum will be enforced. Please note that this attribute is applied to all fee types supported. Also, note that a specified maximum value is checked after enforcing a specified minimum value, and hence a specified maximum value trumps a specified minimum.

🔹 Min

If a minimum value for the fee is specified and is greater than zero, then if the computed fee is less than this minimum value, then the minimum value will be used instead. If no minimum value is specified or is set to a value of zero, then no minimum will be enforced. Please note that this attribute is applied to all fee types supported. Also, note that a specified minimum value is checked before enforcing a specified maximum value, and hence a specified maximum value trumps a specified minimum.

🔹 Name

This attribute is for convenience purposes only, and does not affect the calculation of the fee in any manner. However, the value of this attribute will be used to identify the fee in the returned response, and hence it is highly recommended that you name your fees accordingly.

🔹 Position

Fees influence a loan depending on when they are applied.

• OnAdvance - The fee is included in the application of an advance.
• BeforePmt - When the fee occurs on the same date as a payment, the fee is calculated before the payment amortizes the loan.
• InPmt - The fee is included as part of the payment.
• AfterPmt - When the fee occurs on the same date as a payment, the payment first amortizes the loan, then the fee is calculated and applied.
• NotInPmt - The fee is paid on the same date as a payment but is not reflected in that payment. If the fee has AddToFinChg="true", it is called a “Pocket APR” fee; otherwise it is a straight “Pocket Fee”.
• Default - means different things, depending on when the fee occurs. A fee on an advance is treated as if OnAdvance were selected. A fee on a payment is treated as if InPmt were selected.

🔹 PPY

PPY is an abbreviation for payments per year, and in the case of the <Fee> element, determines the frequency for the fee stream. If the value of the Term field is 1, then the value of this field is ignored.

🔹 Round

The value of this attribute, along with the with the RoundBasis attribute described below, determine how the amount on which the fee is based is to be rounded.

For fee calculation types of OnPrincipal, OnProceeds, OnAmtFin, OnBalance, and OnBalanceFlat, the amount on which the fee is based is fairly self evident: the starting principal balance, proceeds, amount financed, or the outstanding balance at the time that the fee is assessed. Thus, if the calling application requires a fee to be computed based upon 0.35% of the principal balance rounded to the nearest $100, then the fee element would look something like this:

<Fee Name="DocStamp" CalcType="OnPrincipal" Amount="0.35" RoundBasis="100.00"
   Round="nearest" AddToPrin="true" AddToFinChg="false" />

For the Dollar fee calculation type, the amount on which the fee is based is defined as the fee amount passed into the engine. This allows the calling application to pass in a precomputed fee amount and have the SCEX round it as directed. As an example, here is the definition of a dollar fee which is rounded up to the next dollar (the value of the fee below would then be $25 after rounding):

<Fee Name="DocStamp" CalcType="Dollar" Amount="24.25" RoundBasis="1.00"
   Round="up" AddToPrin="true" AddToFinChg="false" />

For the ServChg fee calculation type, the amount on which the fee is based is defined as the computed service charge amount, as defined by the Amount and ServChgType attributes.

🔹 RoundBasis

When rounding the amount on which the fee is based, the value of this attribute determines the precision to which rounding is performed. The default value of 0.01 indicates that the rounding should be done to the penny, whereas a value of 100.0 indicates that rounding should take place to the nearest hundred dollars.

🔹 SemimonthlyDay

When specifying a semimonthly fee stream, the day number on which the first fee is added determines the day number for all of the following odd numbered events. If you omit this attribute or specify a value of 0, then the even numbered events will be generated using the default method within the SCE.

If you wish to specify the day number on which even numbered events fall (overriding the default method used in the SCE), then set the value of this attribute to the desired day number. Setting the value of this attribute to 31 will cause all even events to fall on the last day of the month.

As an example, if you want to specify a semi-monthly $10 fee stream beginning on January 1, 2015 with fees that fall on the 1st and 15th of each month for 48 fees, the element should look something like this:

<Fee Name="Test Fee" Date="2015-01-01" Amount="10" Term="48" PPY="24"
   SemimonthlyDay="15" />

🔹 ServChgType

This attribute dictates whether or not a fee is treated as a service charge, and if so, determines how the service charge dollar amount is paid off over the term of the loan. If a fee should not be treated as a service charge, then the default value of None should be specified.

• ByTerm - means that the service charge is paid off by dividing the amount by the Term attribute of the same <Fee> element.
• ByDays - means that the service charge is paid off on payment dates. The amount of the fee is calculated as the number of days from the previous payment (or advance) divided by the total number of days in the term of the fee.

🔹 Term

The term attribute determines the the number of fees to be included at the specified frequency (see PPY below), after which the fee stream is completed. The default value is 1. If the value of the Date attribute is not a valid date, then the value of this attribute is ignored.

🔹 Weekends

If fee dates (including the specified start date) are not allowed to fall on a Saturday or Sunday, then set the value of this field to something other than Ignore. The meaning of the other three values are defined below:

• Prev - The date will be moved to the Friday before the computed weekend date.
• Near - The date will be moved to the Friday before the computed weekend date if the computed weekend date falls on a Saturday, otherwise it will be moved to the Monday after.
• Next - The date will be moved to the Monday after the computed weekend date.

Note that two other attributes can cause the computed dates to be adjusted - AllowFeb29 and Weekends. For a complete description of how these three ideas work together, please see the documentation for the Holidays attribute.

🟦 <Format>

The <Format> element is one of the first elements parsed from a request, as the attributes of this empty element affect how date and numeric values are parsed and validated.

Attributes: 🔹CurrencyDecimals, 🔹DateFormat, 🔹DateSeparator, 🔹DecimalSeparator, 🔹StrictDP, 🔹ThousandSeparator

🔹 CurrencyDecimals

When displaying and parsing Currency values, the value of this attribute determines the maximum number of decimal places allowed after the DecimalSeparator.

🔹 DateFormat

When displaying and parsing Date values, this field determines the expected format for all Date fields. The following DateFormat options are allowed:

• YMD - All dates should be formatted as YYYY-MM-DD.
• MDY - All dates should be formatted as MM-DD-YYYY.
• DMY - All dates should be formatted as DD-MM-YYYY.

Note that the character which separates the individual month, day, and year portions of the date is configurable via the DateSeparator attribute.

🔹 DateSeparator

When displaying and parsing Date values, this attribute determines the character used to separate the individual month, day, and year portions of a date.

🔹 DecimalSeparator

When displaying and parsing Currency or Decimal numeric values, this attribute determines the character used to separate the fractional part from the whole.

🔹 StrictDP

If the value of this attribute is true, then the SCE will strictly verify the number of decimal places allowed for currency input values. Thus, if the calling application sends in a request with a currency amount of 1000.005, the SCE will return an error code.

If the value of this attribute is false, then currency values sent in with an invalid number of decimal places will be rounded to the correct number of decimal places by the SCE (using five/four rounding), and a warning message with this information will be returned with the response.

🔹 ThousandSeparator

When displaying numeric values, this attribute determines the character used to separate the thousands places from the hundreds. Note that when parsing numeric values, the value of this attribute is ignored.

🟦 <Holiday>[]

If dates for <PmtStream> and <Fee> elements have requested that holidays be skipped (e.g., the Holidays attribute for the element in question is set to a value other than Ignore), then the request must specify each holiday to be considered, with each holiday requiring at least one <Holiday> element.

The <Holiday> element itself is empty, as all required information for each holiday is specified as an attribute of this element.

Attributes: 🔸Date

🔸 Date

The Date attribute lets the calling application specify a holiday using one of the following formats:

• YYYY-MM-DD - A holiday can be defined by sending in a valid date, where YYYY is greater than or equal to 1900, MM is a valid month, and DD is a valid day for the given year and month.
• 0000-MM-DD - A holiday that occurs annually on the same month and day can be defined by sending in a valid month and day, with the year passed in as 0000. As an example, in the United States of America, Christmas is a Federal holiday celebrated on December 25th of each year. To pass this holiday into the SCEX, the <Holiday> element would look like <Holiday Date="0000-12-25" />.
• 0001-MM-PD - A holiday that occurs annually in the same month on a given day of the week (D) in a given position in the month (P) can be defined by sending in a valid month, position, and day of the week, with the year passed in as 0001. The value of D can be from 0 to 6, where 0 = Sunday, 1 = Monday, ..., 6 = Saturday. The value of P can be from 1 to 6, where 1 = 1st, 2 = Second, ..., 5 = 5th, 6 = last. As an example, in the United States of America, Thanksgiving is a Federal holiday celebrated on the 4th (P=4) Thursday (D=4) of November (MM=11) every year. To pass this holiday into the SCEX, the <Holiday> element would look like <Holiday Date="0001-11-44" />.
• 0002-NN-NN - A holiday that occurs annually but cannot be expressed using any of the above methods. Currently, the following special holidays are recognized by the SCEX:
• 0001 - Good Friday
• 0002 - Easter Sunday
• 0003 - Easter Monday

🟦 <Mortgage_Insurance>

The <Mortgage_Insurance> element determines if this loan includes one of the supported types of mortgage insurance (MI) - PMI or FHA. This element contains child elements which further specify mortgage insurance options.

NOTE: Mortgage insurance is only supported on equal, balloon, and interest only loan builder requests at this time.

Attributes: 🔹CashDown, 🔹LoanAmt, 🔸PropertyValue, 🔹Type

🔹 CashDown

The CashDown attribute represents a cash down payment made at closing. If specified and greater than zero, this amount will be deducted from the principal balance. If not specified, the cash down payment will default to zero.

🔹 LoanAmt

The LoanAmt attribute represents the amount by which the PMI rates are multiplied to produce a level PMI premium. If not specified, then the principal balance will be used to compute the annual premium.

🔹 PropertyValue

This attribute’s value represents the appraised property value, and will be used in the calculation of the loan to value ratio.

🔹 Type

This attribute determines the type of mortgage insurance to include with the loan. If the Type attribute is set to FHA, a different MI premium is computed every twelve months based upon the average outstanding principal balance during that same term. The MI calculation adheres strictly to the HUD regulation.

🟥 <Mortgage_Insurance>→<MI_Rate>[]

The value of this element specifies the cost of mortgage insurance per $100 of the loan amount. Note that there may be more than one <MI_Rate> element defined in an XML loan request (see the Switch attribute below).

As an example, a loan computed with a MI rate of $1.50 per $100 would be specified as <MI_Rate>1.50</MI_Rate>.

Attributes: 🔸Switch

🔹 Switch

This optional attribute defines the payment number beyond which the associated MI rate will apply. If not specified, the value will default to zero.

Thus, if there is only a single MI rate, one may omit this attribute. Single rate example (use a rate of $1.50 for the entire term of MI coverage):

<MI_Rate>1.50</MI_Rate>

Multiple rate example (use a rate of $1.50 for the first 10 years, with a rate of $0.20 for coverage beyond 10 years):

<MI_Rate>1.50</MI_Rate>
<MI_Rate Switch="120">0.20</MI_Rate>

🟦 <Mortgage_Insurance>→<Periodic>

The value of this element represents the term beyond which MI is no longer included. As an example, if mortgage insurance must be removed after the 180th payment, then the calling application should specify <Periodic>180</Periodic> in the XML loan request. 0 means no term removal is in effect.

Attributes: 🔹DropLTV, 🔹WarnLTV

🔹 DropLTV

The value of this attribute determines the loan to value ratio at which MI should be removed, and is expressed as a percentage. For example, if you wish to automatically drop MI when the loan to value ratio first equals or falls below 78%, then you would specify DropLTV="78.0".

🔹 WarnLTV

The value of this attribute determines the loan to value ratio at which a warning should be issued, and is expressed as a percentage of LTV (loan to value). For example,if you wish to know when the loan to value ratio first equals or falls below 80%, then you would specify WarnLTV="80.0".

🟦 <Mortgage_Insurance>→<UpFront>

This element determines the up front fee for mortgage insurance, as disclosed in the <PMI_Fee> element in the results. If this element is not specified, no up front fee will be computed. Note that ZOMP (zero option monthly premium) products do not have an up front fee, which means that this element can be omitted or set to zero.

The following attributes define how the fee is computed and disclosed.

Attributes: 🔹Paid, 🔹Units

🔹 Paid

If the value of this attribute is set to Financed, then the computed up front fee will be added to the principal balance and the finance charge. A value of AtClosing will cause the value of the fee to be added to the finance charge alone. Finally, a value of ByLender means that the up front fee is to be paid by the lender; hence, the value of the fee is a Pocket Fee that is not added to either the principal balance nor the finance charge.

🔹 Units

If the Units attribute is set to Months, the value of the <UpFront> element represents the number of periodic MI premiums to be paid at closing.

If the Units attribute is set to Years, the value of the <UpFront> element represents the number of annual MI premiums to be paid at closing.

Many single premium products define the up front fee as a number of years of MI to be paid up front.

Finally, if the Units attribute is set to Points, the value of the <UpFront> element represents the percentage of principal to be paid up front. As of October 3, 2011, FHA loans use points.

🟦 <OddDaysPrepaid>

If odd days interest should be treated as a prepaid finance charge or added to the first payment, then include this empty element in the request. The attributes of this element determine how odd days interest is computed and handled.

Attributes: 🔹AccrualCode, 🔹AddToPmt, 🔹AddToPrin, 🔹AnchorDate, 🔹ForceUnitPeriod, 🔹NoCap, 🔹UseDailyCost, 🔹UseNegODI

🔹 AccrualCode

The accrual code defines how the odd days interest is computed.

Note that accrual code 250 ("Variable Days Per Year") defines the basis divisor days to be equal to 12 multiplied by the number of days in the month of the date on which interest begins to accrue. Thus, if the interest start date falls in November, then the number of basis days is 360. If the interest start date falls in a month with 31 days, then the number of basis days is 372. For an interest start date in February, the number of basis days will either be 336 or 348, depending upon whether or not it is a leap year.

🔹 AddToPmt

If the calling application wants the odd days interest to be added to the first payment, then set the value of this attribute to true. A value of false indicates that the odd days interest will be treated as a prepaid fee.

🔹 AddToPrin

If any odd days interest should be treated as a financed prepaid fee, then set the value of this attribute to true. Note that if both AddToPmt and AddToPrin are set to true, then a warning message will be returned by the SCEX and the value of AddToPrin will be set to false.

🔹 AnchorDate

The computed number of odd days is the number of days between the loan date and the anchor date. This attribute determines how to arrive at the anchor date.

• BackUnitPeriod - The anchor date is one unit period prior to the specified first payment date.
• BackDaysPerPeriod - The anchor date is the number of days per period prior to the first payment date.

Please note that for both of these methods, the period used will be that associated with the payment stream in which the first payment occurs.

🔹 ForceUnitPeriod

If the loan's interest accrual is unit period, this attribute forces the period to the first payment to be 1/12 (or 1/(PmtsPerYear) in general). Without this attribute an accrual code of 202 (Unit Period /365) would use a factor of Days/365 rather than the expected 1/12.

🔹 NoCap

When an odd days interest fee is present and financed, the value of this attribute determines if the ODI fee is added to the principal balance for the purposes of computing the ODI fee (e.g. if it is capitalized). If this value is true, the ODI is computed on the true principal balance less the ODI; false means "compute ODI on the true principal balance.

🔹 UseDailyCost

If the total odd days prepaid fee is computed by first generating a rounded (to the nearest penny) daily cost and then multiplying this value by the computed number of odd days, then set the value of this property to true.

A value of false means that the daily cost is left unrounded, and the total prepaid fee is rounded after the computation is complete.

🔹 UseNegODI

If there are negative odd days in the loan, then the value of this attribute determines if a negative odd days interest fee is computed. If the value of this attribute is false, then negative odd days fees are not allowed, the SCEX will return a value of zero in this situation, and the computed payment will be adjusted to take into account the negative odd days. A value of true will return a negative odd days interest fee (in effect, it then becomes an odd days interest credit) when there are negative odd days in a loan.

🟦 <PmtStream>[]

Payment streams are defined using the attributes of this empty element, including individually defined payments.

Attributes: 🔹AllowFeb29, 🔹Amount, 🔸Begin, 🔹ComputeTerm, 🔹Holidays, 🔹LastDay, 🔹MinPmt, 🔹PmtType, 🔹PPY, 🔹ReplaceIdx, 🔹SemimonthlyDay, 🔹Term, 🔹Weekends

🔹 AllowFeb29

This attribute is used when generating payment dates (if any) beyond the specified Begin date of the <PmtStream> element. If the value of this attribute is true, then February 29th is an allowed payment date.

On the other hand, if the value of this attribute is set to false and a computed date in the given payment stream is scheduled to fall on February 29th, then the scheduled payment date will be altered in one of the following manners:

• If the number of payments per year is 1, 2, 4, 6, 12, or 24 then the scheduled payment date of February 29 will be moved back one day to February 28. This is the only date that will be adjusted.
• If the number of payments per year is 26 or 52 then the scheduled payment date of February 29 will be moved forward one day to March 1, and all subsequent payment dates will be a multiple of 7 or 14 days from this date (depending upon the specified payment frequency).

🔹 Amount

The meaning of the Amount attribute depends on the PmtType attribute.

• CalcPmt - If the value of this attribute is a currency value (e.g. Amount="####.##"), then the value will be added to the calculated payment (also known as a "pickup payment"). If the suffix of the value is % (e.g. Amount="50%) then the value before the % suffix will be treated as a percentage, and the payment will be equal to the specified percentage of the computed payment.
• FixedPmt - The amount of the fixed payment. An Amount="0" means a skipped payment. If the suffix of the value is % (e.g. Amount="1.0%") then the value before the % suffix will be treated as a percentage, and the payment will be equal to the specified percentage of the loan's disclosed principal balance. Similarly, if the suffix of the value is %B (e.g. Amount="5.0%B") then the value before the %B suffix will be treated as a percentage, and the payment will be equal to the specified percentage of the loan's outstanding principal balance at the time the payment is made.
• PayInt - Addition to the interest only payment. If Amount="0", then it is an interest only payment. If the suffix of the value is % (e.g. Amount="1.0%") then the value before the % suffix will be treated as a percentage, and the principal portion of the payment will be equal to the specified percentage of the loan's disclosed principal balance. Similarly, if the suffix of the value is %B (e.g. Amount="5.0%B") then the value before the %B suffix will be treated as a percentage, and the principal portion of the payment will be equal to the specified percentage of the loan's outstanding principal balance at the time the payment is made. If the suffix of the value is %C (e.g. Amount="50%C) then the value before the %C suffix will be treated as a percentage, and the principal portion of the payment will be equal to the specified percentage of the computed payment.
• PayPrin - The amount of the pure principal reduction (no interest is paid, only principal). These payments may also use the %, %B, and %C suffixes described above for the PayInt payment type.
• PayEsc - Special payment type associated with MYED attribute of the <BusinessRules> element.

🔸 Begin

The Begin attribute defines when the <PmtStream> begins, and has four ways to express when the payment stream begins: on a standard date, on a payment number, every month or the month of a particular year. The special formats are used following a full payment stream of type CalcPmt. As an example of how convenient these special format are, consider a ten year teacher's loan that skips summer months. This task would require a voluminous list of <PmtStream> elements, were it not for the Month Number format described below.

The formats are as follows:

• Standard Date (YYYY-MM-DD)

The Begin attribute for the <PmtStream> element is generally used to specify the starting date for the payment stream in question. As an example, if the payment stream should begin on Feb. 1, 2008, the attribute should be specified as Begin="2008-02-01".

For payment frequencies that are monthly multiples, the day number specified in this attribute specifies the desired day number of all future payments, if this day number does not exceed the number of days in the computed month. As an example, if the first payment is scheduled to be made in February of 2022 and the desired day for all payments is the 30th, then the attribute would be specified as Begin="2022-02-30".

• Payment Number (nnnn-00-00)

If you wish to replace a previously defined payment by specifying the payment number (n), use a value of nnnn-00-00. For example, an attribute value of 0012-00-00 instructs the engine to replace payments starting on the 12’th payment. If the value of the Term attribute is greater than one, then that number of payments will continue to be replaced.

Example: To define a stream of 12 interest only payments followed by 48 computed payments, the following XML could be used:

<PmtStream PmtType="CalcPmt" Begin="2014-12-20" Term="60" PPY="12" />
<PmtStream PmtType="PayInt" Begin="0001-00-00" Term="12" PPY="12" />

• Month Number (0000-mm-00)

If a special payment is to occur on a specific month every year, use this format. The following example skips the summer months of June, July and August on a ten-year teacher's loan:

<PmtStream PmtType="CalcPmt" Begin="2014-12-20" Term="120" />
<PmtStream PmtType="FixedPmt" Begin="0000-06-00" Amount="0" />
<PmtStream PmtType="FixedPmt" Begin="0000-07-00" Amount="0" />
<PmtStream PmtType="FixedPmt" Begin="0000-08-00" Amount="0" />

• Month of a Year (yyyy-mm-00)

If only the month of a particular year needs adjusting, use the "yyyy-mm-00" format. e.g. A value of 2011-08-00 instructs the SCEX to use the defined payment for every payment occurring in August of 2011 (there can be more than one payment if the payment frequency is greater than monthly).

NOTE - if the value of the Begin attribute is not a valid date (i.e. it is instead of one of the three formats mentioned above), then the LastDay, Term, and PPY attributes will be ignored, unless otherwise noted above.

🔹 ComputeTerm

If set to true, then the ComputeTerm attribute is used to inform the Loan Builder module that the calling application is requesting an equal payment “roll to term” loan calculation. In this loan scenario, the calling application specifies the interest rate, amount requested, maximum desired payment amount, and maximum loan term. The Loan Builder module will then compute the shortest term to produce an equal payment amount less than or equal to the specified maximum payment.

As an example, the following partial XML request would direct the Loan Builder module to compute the term for an equal payment loan with an interest rate of 5.00%, an advance of $5,000, a maximum desired payment amount of $300, and a maximum allowed loan term of 60 monthly payments:

<Advance Date="2021-08-01" Amount="5000.00" />
<EditInterest Date="2021-08-01" IntRate="5.000" />
<PmtStream Begin="2021-09-01" PmtType="FixedPmt"
           Amount="300.00" Term="60" ComputeTerm="true" />

Note that in the above partial XML request, the PmtType must be set to FixedPmt, the value of the Amount attribute is set to the maximum desired payment amount, and the value of the Term attribute is set to the maximum term allowed.

🔹 Holidays

If payment dates (including the specified start date) are not allowed to fall on specified holidays (see the <Holiday> element for more information on how to specify holidays), then set the value of this field to something other than Ignore. The meaning of the other two values are defined below:

• Ignore - No holidays will be considered.
• Prev - The date will be moved to the day before the holiday.
• Next - The date will be moved to the Monday after the holiday.

Note that two other <PmtStream> element attributes can cause the computed dates to be adjusted - AllowFeb29 and Weekends. The rules for how these three fields interact are described below in detail.

For every date required in our payment stream, the SCE goes through the following steps:

1. Generate the next date in our date stream, called the target date.
2. If February 29th is not allowed and if the target date is 2/29, then adjust the target date forward or backward one day based upon the date generation frequency. If the frequency is a monthly multiple, then the target date is moved backward one day to 2/28. Weekly and biweekly frequencies move the target date forward one day to 3/1.
3. If weekend dates are not allowed (e.g. the Weekends attribute holds a value other than Ignore) and the target date falls on a Saturday or Sunday:
   • (a) then adjust the target date according to the attribute value.
   • (b) if February 29th is not allowed and if the target date is 2/29, then adjust the target date in the same direction as in 3(a) above.
4. If holidays are not allowed (e.g. the Holidays attribute holds a value other than Ignore) and the target date falls on a specified holiday:
   • (a) then adjust the target date according to the Holidays attribute value.
   • (b) If weekend dates are not allowed (e.g. the Weekends attribute holds a value other than Ignore) and the target date falls on a Saturday or Sunday, then adjust the target date in the same direction as in 4(a) above.
   • (c) if February 29th is not allowed and if the target date is 2/29, then adjust the target date in the same direction as in 4(a) above.
   • (d) Step 4 is repeated until the target date is not adjusted.

🔹 LastDay

This attribute is used to resolve ambiguities in subsequent payment dates when the Begin date falls on the last day of a month with fewer than 31 days. If the value of the Begin attribute is not a valid date, then the value of this attribute is ignored. If the value of the Term attribute is 1, then the value of this attribute is ignored.

Set this attribute’s value to true if the intent was to make subsequent payments occur on the last day of the month. A value of false indicates that subsequent payment dates will fall on the day number specified by the Begin date.

As an example, if the calling application specifies a Begin date of 2010-02-28, then subsequent payment dates for a monthly payment frequency will be:

• on the 28th of each subsequent month if LastDay="false".
• on the last day of each subsequent month if LastDay="true".

🔹 MinPmt

If specified, this field will dictate a minimum payment. If a calculated payment falls below the specified minimum payment value, then the minimum payment value will be used instead.

When a minimum payment is used, the principal reduction of the loan will be accelerated. In some loan scenarios, this will result in an early payoff of the loan before the specified Term of the payment stream. In this situation, the final payment will always pay off the loan, and will be smaller than the specified minimum payment.

🔹 PmtType

Various types of payment streams may be requested by use of this attribute.

• CalcPmt - Compute target payment(s) that defines a common payment.
• FixedPmt - Payments in this stream are specified as the Amount attribute. If the Amount="0", the payment is skipped.
• PayInt - Interest only payments with or without additional principal defined as the Amount attribute.
• PayPrin - Pure principal payment. Interest accrued will persist as unpaid interest beyond the pure principal payment.
• PmtEsc - Escrow the payments. Each payment will increase a pool of escrowed payments that amortize the loan on the year-end date. (See MYED attribute of the <BusinessRules> element).

Same Day Payments - By design or chance, payments can land on the same calendar day. How they behave depends on the combination of PmtType attributes. All possible combinations are considered below:

• CalcPmt + CalcPmt - Merge into one CalcPmt event whose Amount is equal to the sum of the individual Amount attributes.

• CalcPmt + FixedPmt - Replace the CalcPmt with the FixedPmt.

• CalcPmt + PayInt - Replace the CalcPmt with the PayInt.

• CalcPmt + PayPrin - If the PayPrin Amount is specified as a fixed dollar amount, increase the CalcPmt Amount by the PayPrin Amount and delete the PayPrin event. Otherwise, keep both payments.

• FixedPmt + FixedPmt - Retain both payments separately.

• FixedPmt + PayInt - Retain both payments separately.

• FixedPmt + PayPrin - Retain both payments separately.

• PayInt + PayInt - Merge into one PayInt event whose Amount is the sum of the two PayInt Amount attributes.

• PayInt + PayPrin - Merge into one PayInt event, with the PayPrin Amount added to the PayInt Amount.

• PayPrin + PayPrin - Merge into one payment, adding the Amount attributes together.

🔹 PPY

PPY is an abbreviation for payments per year, and as one might surmise, determines the payment frequency for the payment stream. If the value of theBegin attribute is not a valid date, then the value of this attribute is ignored.

🔹 ReplaceIdx

The ReplaceIdx attribute allows applications to restrict the enforcement of a replacement payment to a specific <PmtStream>. If specified, the value of ReplaceIdx must be an integer >= 0. If not included in the request, then ReplaceIdx will be set internally to a value of -1, which means that this replacement payment rule will be applied to all matching payments.

If specified, the value of ReplaceIdx represents the numeric index of the <PmtStream> element to which the replacement payment will only be applied.

Example 1:

<!-- 2 overlapping payment streams -->
<PmtStream Begin="2024-01-01" Term="36" PmtType="PayInt" />
<PmtStream Begin="2024-01-01" Term="36" PmtType="PayPrin" Amount="1000" />

<!-- Replacement payment streams target only the “PayPrin” stream above -->
<PmtStream Begin="0000-01-00" PmtType="FixedPmt" ReplaceIdx="1"/>
<PmtStream Begin="0000-03-00" PmtType="FixedPmt" ReplaceIdx="1"/>
<PmtStream Begin="0000-04-00" PmtType="FixedPmt" ReplaceIdx="1"/>

In the example above, the first <PmtStream> with a PmtType of PayInt has an index of 0, with the PayPrin payment stream having an index of 1, etc.

All three replacement payment streams (with indexes of 2, 3, and 4) indicate that they are targeting the PayPrin payment stream only by specifying ReplaceIdx="1". Also note that once the replacement payments are applied to the applicable payments, those payments will no longer be considered to be a part of the original payment stream, but instead will be considered to be a part of the replacement payment stream that was applied.

Example 2:

Assume we wanted to build a repayment schedule of 24 interest only payments, followed by 36 computed equal payments. Also, assume that we wanted to skip the interest only payments made in December. Then, we could build a request in the following manner:

<PmtStream Begin="2024-06-01" PmtType="CalcPmt" Term="60" />
<PmtStream Begin="0001-00-00" PmtType="PayInt" Term="24" />
<PmtStream Begin="0000-12-00" PmtType="FixedPmt" ReplaceIdx="1" />

Above, PmtStream[0] sets up the basic repayment schedule with 60 computed equal payments. Then, PmtStream[1] replaces payments 1-24 with interest only payments. Finally, PmtStream[2] replaces the December payment in the interest only period with a skipped payment.

If you are creating overlapping payment streams with payments that fall on the same day, then we recommend that you set the value of the Merge attribute of the <EditOutput> element to false. If Merge is left at its default value of true, merging of payments occurs before replacement payments are enforced, thus making targeting a given payment stream much more difficult if they are merged with a payment from a second payment stream.

🔹 SemimonthlyDay ([0..31], 0)

When specifying a semimonthly payment stream, the day number on which the first payment is made determines the day number for all of the following odd numbered payments. If you omit this attribute or specify a value of 0, then the even numbered payments will be generated using the default method within the SCEX.

If you wish to specify the day number on which even numbered payments fall (overriding the default method used in the SCEX), then set the value of this attribute to the desired day number. Setting the value of this attribute to 31 will cause all even payments to fall on the last day of the month.

As an example, if you want to specify a semi-monthly payment stream beginning on January 1, 2014 with payments that fall on the 1st and 15th of each month for 24 payments, the element should look something like this:

<PmtStream PmtType="CalcPmt" Begin="2014-01-01" Amount="0" 
    Term="24" PPY="24" SemimonthlyDay="15" />

🔹 Term

The term attribute indicates the the number of payments to be made at the specified payment frequency (see PPY above), after which the payment stream is completed. The default value is 1. If the value of the Begin attribute is not a valid date, then the value of this attribute is ignored.

🔹 Weekends

If payment stream dates (including the specified start date) are not allowed to fall on a Saturday or Sunday, then set the value of this field to something other than Ignore. The meaning of the other three values are defined below:

• Prev - The date will be moved to the Friday before the computed weekend date.
• Near - The date will be moved to the Friday before the computed weekend date if the computed weekend date falls on a Saturday, otherwise it will be moved to the Monday after.
• Next - The date will be moved to the Monday after the computed weekend date.

Note that two other attributes can cause the computed dates to be adjusted - AllowFeb29 and Weekends. For a complete description of how these three fields work together, please see the documentation for the Holidays attribute.

🟦 <Protection>

If the calling application wishes to add any payment protection products to the loan (e.g. credit insurance or debt protection), then this element and at least one <Product> child element must be present.

Attributes: 🔹DataDirPath, 🔹ShowDataPath

🔹 DataDirPath

If this attribute is set, the SCEX will look for a data folder containing the setup files in the path specified. Thus, if the DataDirPath is set to C:\SCEX\, the SCEX will look for the setup files in C:\SCEX\data.

If the calling application wishes to specify the data directory path in its entirety (e.g. the calling app does not want the SCEX to append \data to the provided path), then simply terminate the specified DataDirPath with an asterisk (*). Thus, if the DataDirPath is set to C:\SCEX\bank1\*, the SCEX will look for the setup files in C:\SCEX\bank1\.

If this attribute is not set, the SCEX will attempt to locate the data folder in the default data directory path location, which can be retrieved using the <inVERSION> module query, and set via the SCEX API.

This attribute is useful if you wish to use only a single installation of the SCEX, but have many different setup file groupings. By specifying a different DataDirPath for each grouping, you can easily separate the groups from one another instead of grouping them all together in a single directory.

🔹 ShowDataPath

This attribute determines if the data directory path used in the calculation of the loan will be disclosed in the response as an attribute of the <Protection> element.

🟦 <Protection>→<Product>[]

Each protection product is individually defined through the use of a <Product> element (along with its child elements).

As an example, if a loan was requested with single decreasing life, single disability, single involuntary unemployment, and joint property insurances, then the input XML detailing the protection requests would look similar to the following:

<Protection DataDirPath="c:\scex\">
  <!-- Credit Life -->
  <Product Code="CL">
      <Birthday>1966-04-16</Birthday>
  </Product>
  <!-- Accident and Helth -->
  <Product Code="AH">
      <Birthday>1969-11-21</Birthday>
  </Product>
  <!-- Involuntary Unemployment -->
  <Product Code="IU">
      <Birthday>1966-04-16</Birthday>
  </Product>
  <!-- Personal Property -->
  <Product Code="PP">
      <Birthday>1966-04-16</Birthday>
      <Birthday>1969-11-21</Birthday>
  </Product>
</Protection>

Note: Life (Code="CL") may end up with two resulting products - decreasing and level, depending on the loan type and protection parameters.

Attributes: 🔹Account, 🔹Code, 🔹Dismemberment, 🔹Financed, 🔹Method, 🔹ShowFactor, 🔹Table, 🔹UseLevelRates

🔹 Account

This attribute specifies the account number that will be used to define the requested product. Each account is numbered from 1 to 9,999, and each account corresponds to a set of setup file which define numerous settings which define the product and how it is calculated, such as the insurance rates, caps, formulas used, etc. If this attribute is not specified, a default value of 1 will be used.

🔹 Code

This attribute defines the type of payment protection product, and which setup files are references for calculation, rate, and cap purposes. In the description of each product below, ‘NNNN’ is the Account number (see above, an account number of 1 would thus be ‘0001’).

• LI – The requested product is treated as decreasing credit life and will reference the clNNNN.ini setup file.
• AH – The requested product is treated as accident and health and will reference the ahNNNN.ini setup file.
• IU – The requested product is treated as involuntary unemployment and will reference the iuNNNN.ini setup file.
• PP – The requested product is treated as property insurance and will reference the ppNNNN.ini setup file.

🔹 Dismemberment

If the account specified has been set up to offer life protection products with optional dismemberment coverage, and if the optional dismemberment coverage is desired, then set this attribute’s value to true. Otherwise, use the default value of false.

🔹 Financed

Single premium protection products are typically financed (added to the principal balance). If you wish to have the premiums paid up front at loan cloasing, then set the value of this field to false.

🔹 Method

Some accounts are configured to offer different types of credit life products (usually gross and net). In these accounts, this field allows the calling application to specify which method to use for a given loan. If no method is present in the request, then the default method will be used.

🔹 ShowFactor

If this attribute is set to true, then the <Cost> output element (child element of <Product>) will include a Factor attribute which is useful to Sherman and Associates when debugging protection calculations.

🔹 Table

When requesting the accident and health product (e.g. the Code attribute of <Product> element is set to AH), if the specified account has been set up with multiple disability or debt cancellation plans, then this attribute determines which plan number will be used. If no table number is specified, the first table (table zero) will be used. To find out the number of available plans, use the <AHSetCount> element returned from an <inINPUT_TOOL> query.

If the requested product Code is not AH, then this attribute is ignored.

🔹 UseLevelRates

If the account specified has been set up to offer single premium credit life using level rates instead of the normal decreasing rates, then set this attribute’s value to true. Otherwise, use the default value of false.

🟦 <Product>→<Benefit>

If you wish to specify a benefit amount less than the maximum allowed, then do so with this element. Omitting this element will assure that the maximum benefit amount allowed will be used in the loan calculation. Note that if the specified account has not been set up to allow for user specified benefit amounts for the product in question, or if the product itself does not have the notion of a monthly benefit (such as life and property products), then this element will be ignored.

Attributes: None

🟥 <Product>→<Birthday>[]

This element contains the date of birth for a borrower who is requesting a payment protection product. The type of coverage provided (e.g. single or joint) is determined by the number of <Birthday> child elements for each <Product> element. Thus, to request single accident and health coverage, the <Product> element (with Code=“AH”) requires a single <Birthday> child element containing the birthday of the borrower seeking coverage. Similarly, to request joint decreasing life coverage, the <Product> element (with Code=“CL”) requires two <Birthday> child elements, each of which contains the birthday of a borrower seeking coverage.

Since the type of coverage depends upon the number of <Birthday> elements present, at lease one must appear and no more than two are allowed (as the only coverage options are single or joint).

All dates must be in the form of YYYY-MM-DD, and be 10 characters long.

Attributes: None

🟦 <Product>→<Coverage>

If you wish to specify a coverage amount less than the maximum allowed, then do so with this element. Omitting this element will assure that the maximum coverage amount allowed will be used in the loan calculation. Note that if the specified account has not been set up to allow for user specified coverage amounts for the product in question, then this element will be ignored.

Attributes: None

🟦 <Product>→<Term> (integer, 0)

If you need to specify a coverage term (in months or payments) less than the maximum allowed, then do so using this element. If this element is omitted, then the loan will be covered for the maximum term allowed. Note that if the specified account has not been set up to allow for user specified coverage terms for this product, then this element will be ignored.

Attributes: 🔹Units

🔹 Units

The specified numeric coverage term will be interpreted as a number of payments or months, depending upon the value of this attribute.

🟦 <TILARESPA2015>

If this element is present in the request, then the SCE will return data for the Integrated Mortgage Disclosures under the Real Estate Settlement Procedures Act (Regulation X) and the Truth In Lending Act (Regulation Z) rule, which is required as of August 1st, 2015. If this element is not present, then the TILA RESPA outputs will not be generated.

Attributes: None

Loan Builder - Response

Please see the Legend to understand the conventions used to document each element and attribute. Note that for responses, the XML elements are documented in the order that they appear in the response.

🟥 <outLOAN_BUILDER>

This element is the root parent element that contains all of the relevant outputs. If a Country code was provided in the request, the following attribute will be included.

Attributes: 🔹Country, 🔹CurrencyDP

🔹 Country

If a valid Country code was specified as an attribute of the input module element, the full name of the country associated with the specified Country code will be reported in this optional attribute.

🔹 CurrencyDP

The number of decimal places that define the currency of the calculation.

🟥 <Results>

This element contains child elements which describe the success or failure of the calculation, as well as any XML messages.

<Results>
  <Description>Successful Calculation</Description>
</Results>

Attributes: None

🟥 <Results>→<Description>

If the calculation was completed successfully, then this element will contain the value Successful Calculation. Otherwise, this element will contain a description of the problem encountered during the attempted computation.

Attributes: None

🟦 <Results>→<Note>[]

The <Note> elements present important calculation comments to more fully explain outputs that may either not be apparant in the inputs or have overriden input assumptions. These notes are thoroughly detailed in the Appendix titled `Calculation Notes'.

Attributes: 🔹Code

🔹 Code

The unique integer identifying the <Note> in question. This Code may be useful if the calling application would like to override the default description or check for a given note's Code.

🟦 <Results>→<XMLDetail>[]

The <XMLDetail> elements are messages passed back to the calling application which detail the status of the XML request. If the SCEX issues any warnings regarding unrecognized elements or attributes, then each warning message will be displayed in an <XMLDetail> element.

Attributes: None

🟦 <FedBox>

This element groups together all child elements which contain numerical FedBox information, such as the Amount Financed, Finance Charge, Total of Payments, and Regulation Z Annual Percentage Rate.

<FedBox>
  <AmtFin>10070.00</AmtFin>
  <FinChg>1685.80</FinChg>
  <TotPmts>11755.80</TotPmts>
  <RegZAPR Type="Actuarial">10.3420</RegZAPR>
  <MAPR Advance="9960.00" Max="37.000" MaxExceeded="false">11.1001</MAPR>
</FedBox>

Attributes: None

🟥 <FedBox>→<AmtFin>

The Regulation Z Amount Financed, which is defined as the amount of credit provided to you or on your behalf.

Attributes: None

🟥 <FedBox>→<FinChg>

This element contains the Regulation Z Finance Charge, described as the dollar amount the credit extension will cost you.

Attributes: None

🟥 <FedBox>→<TotPmts>

The amount which the borrower will have paid when the borrower has made all scheduled payments.

Attributes: None

🟦 <FedBox>→<TAP>

The total amount payable element is only returned with the response if the value of the ShowTap attribute of the <EditOutput> element in the request is true. The value of this element is computed as the sum of: (i) the total of payments, (ii) all non-financed APR affecting fees, (iii) all out-of-pocket non-APR affecting fees, and (iv) all out-of-pocket APR affecting fees.

Attributes: 🔹Pocket, 🔹PocketAPR, 🔹PrepaidNF

🔹 Pocket

The value of this attribute is the sum of all out-of-pocket non-APR affecting fees. This attribute will only be returned if the value is greater than zero.

🔹 PocketAPR

The value of this attribute is the sum of all out-of-pocket APR affecting fees not paid on an advance. This attribute will only be returned if the value is greater than zero.

🔹 PrepaidNF

The value of this attribute is the sum of all non-financed APR prepaid fees (APR affecting fees paid on the same date as an advance). This attribute will only be returned if the value is greater than zero.

🟥 <FedBox>→<RegZAPR>

The Regulation Z APR, which is the cost of the extension of credit expressed as a yearly rate. The Reg. Z APR element has a few attributes, described below:

Attributes: 🔹Max, 🔹MaxExceeded, 🔸Type

🔹 Max (decimal)

This attribute specifies the maximum APR as specified in the request (see Max). If no maximum APR has been specified, then this attribute will not be present. The value of this attribute should be displayed as a percentage. As an example, for Max="36.000", you would disclose a maximum APR of 36.000%.

🔹 MaxExceeded

If a maximum APR has been specified, then the value of this attribute indicates whether or not the current loan exceeds the maximum allowed APR. As an example, if the maximum APR has been set to 36% and the APR for the returned loan was 37.125%, the <RegZAPR> element would be:

<RegZAPR Type="Actuarial" Max="36.000" MaxExceeded="true">37.125</RegZAPR>`

🔸 Type

This attribute returns the name of the method used to compute the reported APR. The possible values are as follows: Actuarial, [Calendar Name] US Rule, EU_APR, Canadian_APR, Open_End, XIRR, XIRR360, IRR, YieldIRR, and NotComputed.

🟦 <FedBox>→<MAPR>

If the military APR has been requested (see the UseMAPR attribute of the <APR> element), then this element will be included in the output. The value of the element is the military APR, and the element has a few attributes, described below.

Attributes: 🔸Advance, 🔹Max, 🔹MaxExceeded

🔸 Advance

This attribute is the equivalent of the Amount Financed for the Military APR. Specifically, it is the principal balance less any MAPR fees, debt protection, etc.

🔹 Max

This attribute specifies the maximum Military APR as specified in the request (see the MAPR_Max attribute of the <APR> element). If not specified, a default value of 36% is assumed. The value of this attribute should be displayed as a percentage. As an example, for Max="36.000", you would disclose a maximum Military APR of 36.000%.

🔹 MaxExceeded

The value of this attribute indicates whether or not the current loan exceeds the maximum allowed Military APR. As an example, if the maximum APR has been set to 36% and the Military APR for the returned loan was 37.125%, the <MAPR> element would be:

<MAPR Advance="1350.00" Max="36.000" MaxExceeded="true">37.125</MAPR>

🟦 <TILARESPA2015>

This element contains child elements which are of interest to fulfilling the 2015 TILA RESPA rule. It will only be present if the <TILARESPA2015> element is present in the request.

Sample TILARESPA2015 output:

<TILARESPA2015>
  <TotalLoanCosts>0</TotalLoanCosts>
  <CD_TotPmts>27311.07</CD_TotPmts>
  <In5Years PaidTotal="27311" PaidPrincipal="25000"/>
  <TIP>9.244</TIP>
  <MaxPnIPmt Date="2012-11-01">1636.65</MaxPnIPmt>
  <MinRate Idx="1">5.651</MinRate>
  <MaxRate Idx="1">5.651</MaxRate>
  <ProjectedPayments NumCols="3">
      <PPCol Num="1" Title="Year 1">
        <Years Start="1" End="1"/>
        <PnIPmt Min="636.65" Max="1636.65" IntOnly="none" Balloon="false"/>
        <MIPmt>0.00</MIPmt>
        <TotalPmt Min="636.65" Max="1636.65"/>
      </PPCol>
      <PPCol Num="2" Title="Year 2">
        <Years Start="2" End="2"/>
        <PnIPmt Min="636.65" Max="1636.65" IntOnly="none" Balloon="false"/>
        <MIPmt>0.00</MIPmt>
        <TotalPmt Min="636.65" Max="1636.65"/>
      </PPCol>
      <PPCol Num="3" Title="Year 3">
        <Years Start="3" End="3"/>
        <PnIPmt Min="636.65" Max="1636.65" IntOnly="none" Balloon="false"/>
        <MIPmt>0.00</MIPmt>
        <TotalPmt Min="636.65" Max="1636.65"/>
      </PPCol>
  </ProjectedPayments>
</TILARESPA2015>

Attributes: None

🟦 <TILARESPA2015>→<LoanCost>[]

For every <Fee> element present in the input which has its IsLoanCost attribute set to true (and hence, is a borrower paid loan cost) and whose amount is greater than zero (except odd days interest fee types, as explained in the previous documentation of the <Fee> input element), there will be a corresponding <LoanCost> element. The value of this element will be the numerical value of the fee, rounded to the nearest dollar.

Attributes: 🔹In5Years, 🔹Name

🔹 In5Years

If the entire amount of the fee is different from the amount collected over the first five years (for example, a service charge), then this attribute will be present and disclose the portion of this loan cost that is accrued during the first five years.

🔹 Name

This attribute will hold the same value as the attribute of the same name for the <Fee> element. It is recommended that each fee have a unique Name for identification purposes.

🟥 <TILARESPA2015>→<TotalLoanCosts>

This element holds the sum of all borrower paid loan costs. Since all <LoanCost> element values are rounded dollar amounts, the value of this element will also be a rounded dollar amount.

Attributes: None

🟥 <TILARESPA2015>→<CD_TotPmts>

This element holds the sum of the total of payments, all borrower paid loan costs, and any odd days interest that is prepaid at loan closing. This value will be the numerical value of the sum.

Attributes: None

🟥 <TILARESPA2015>→<In5Years>

This element is empty, with all important values required for the new "In 5 Years" section returned in the following two attributes of this element.

Attributes: 🔸PaidPrincipal, 🔸PaidTotal

🔸 PaidPrincipal

This attribute holds "the principal scheduled to be paid through the end of the 60th month after the due date of the first periodic payment". Note that this value is rounded to the nearest whole dollar.

🔸 PaidTotal

This attribute holds the sum of all "principal, interest, mortgage insurance, and borrower paid loan costs scheduled to be paid through the end of the 60th month after the due date of the first periodic payment". Note that this value is rounded to the nearest whole dollar.

🟥 <TILARESPA2015>→<TIP>

The value of this element holds the total interest percentage, rounded to three or fewer decimal places, as required.

Attributes: None

🟥 <TILARESPA2015>→<MaxPnIPmt>

The value of this element holds the maximum scheduled principal and interest payment during the term of the loan.

Attributes: 🔸Date

🔸 Date

This attribute contains the date on which the maximum scheduled principal and interest payment is made. If the maximum scheduled payment occurs more than once, then the date returned is that of the first instance. All dates are in the form of YYYY-MM-DD, and must be 10 characters long.

🟥 <TILARESPA2015>→<MinRate>

The value of this element holds the minimum possible interest rate applied during the term of the loan.

Attributes: 🔸Idx

🔸 Idx

This attribute contains the payment number for which the minimum rate is first applicable.

🟥 <TILARESPA2015>→<MaxRate>

The value of this element holds the maximum possible interest rate applied during the term of the loan.

Attributes: 🔸Idx

🔸 Idx

This attribute contains the payment number for which the maximum rate is first applicable.

🟥 <TILARESPA2015>→<ProjectedPayments>

This element contains child elements which are of interest to filling the Projected Payments table. It will only be present if the <TILARESPA2015> element is present in the XML request for a supported loan type.

Attributes: 🔸NumCols

🔸 NumCols

This attribute will hold the number of columns which must be present in the Projected Payments table. It will be a numeric value from 1 to 4.

🟥 <ProjectedPayments>→<PPCol>[]

For every column required in the Projected Payments table, there will be an associated <PPCol> element. This element is a parent to child elements which contain data associated with a single column of the table.

Attributes: 🔸Num, 🔸Title

🔸 Num

This attribute will hold the number of the column to which the following data applies.

🔸 Title

The value of this attribute is the title for the column. Most of the time, it will be in the form of Years X - Y, or Year X, or Final Payment in the case of a final balloon payment.

🟥 <ProjectedPayments>→<PPCol>→<Years>

The attributes of this element hold the beginning and ending year numbers for which this column data applies. The element itself is empty.

Attributes: 🔸End, 🔸Start

🔸 End

The ending year associated with this column's data.

🔸 Start

The beginning year associated with this column's data.

🟥 <ProjectedPayments>→<PPCol>→<PnIPmt>

This empty element has several attributes which describe the principal and interest payments associated with this column.

Attributes: 🔸Balloon, 🔸IntOnly, 🔸Max, 🔸Min

🔸 Balloon

If any of the payments associated with this column are balloon payments (e.g. isolated payments that are more than twice the value of a regular periodic payment), then the value of this attribute will be true.

🔸 IntOnly

• none - No payments associated with the column are Interest Only
• some - Some, but not all, of the payments associated with the column are Interest Only.
• all - All of the payments associated with the column are Interest Only.

Note that for the purposes of this attribute, a scheduled payment is considered an interest only payment if the payment amount pays off all interest due at the time of the payment, with no reduction in the principal balance.

🔸 Max

This attribute holds the maximum principal and interest payment for this column. If this value is not the same as the value of the Min attribute, then a range of rounded payments must be displayed. If the values are the same, then only a single value needs to be disclosed.

🔸 Min

This attribute holds the minimum principal and interest payment for this column.

🟥 <ProjectedPayments>→<PPCol>→<MIPmt>

The value of this element holds the mortgage insurance premium associated with this column, rounded to the nearest dollar. If no mortgage insurance is present or coverage has been dropped, a value of zero will be present.

Attributes: None

🟥 <ProjectedPayments>→<PPCol>→<TotalPmt>

This empty element has two attributes which describe the estimated total payment or range of payments associated with this column. Note that this value does not include any estimated escrow, as the SCEX does not support escrow calculations. The calling application will need to increase these values by the estimated escrow amounts if any are present.

Attributes: 🔸Max, 🔸Min

🔸 Max

This attribute holds the maximum estimated total payment for this column. If this value is not the same as the value of the Min attribute, then a range of rounded payments must be displayed. If the values are the same, then only a single value needs to be disclosed.

🔸 Min

This attribute holds the minimum estimated total payment for this column.

🟥 <Moneys>

This element groups together those other major cash amounts not disclosed under the <FedBox> element, such as the principal balance, interest change, fee amounts and debt protection premiums.

<Moneys>
  <Principal>10120.00</Principal>
  <Interest>1635.80</Interest>
  <OddDaysPrepaid OddDayCount="15" DailyCost="2.77">41.55</OddDaysPrepaid>
  <FinFees>120.00</FinFees>
  <FinChgFees>91.55</FinChgFees>
  <PocketFees>65.00</PocketFees>
  <MAPRFees>201.55</MAPRFees>
  <Protection Category="None" PerPmt="0.00" PerDay="0.00">0.00</Protection>
  <Fee Name="FinFee">60.00</Fee>
  <Fee Name="MAPR FinFee">60.00</Fee>
  <Fee Name="Prepaid Fee">50.00</Fee>
  <Fee Name="MAPR Pocket Fee">50.00</Fee>
  <Fee Name="Pocket Fee">15.00</Fee>
</Moneys>

Attributes: None

🟥 <Moneys>→<Proceeds>

This element contains the sum of all <Advance> amounts.

Attributes: None

🟥 <Moneys>→<Principal>

The principal balance is the amount on which interest is accrued. The principal balance consists of the amount requested by the borrower, any fees which are financed, as well as financed protection premiums.

Attributes: None

🟥 <Moneys>→<Interest>

This element contains the total interest accrued during the term of the loan, assuming the borrower will make all scheduled payments.

Attributes: None

🟦 <Moneys>→<FinFees>

This element contains the sum of all <Fee> elements having AddToPrin set to true and occuring the date of an advance. If this element's value is zero, it will not show up in the results.

Attributes: None

🟦 <Moneys>→<Prepaid>

This element represents all prepaid finance charges and contains the sum of all <Fee> elements occurring on an advance and having AddToFinChg set to true. If this element's value is zero, it will not show up in the results.

Attributes: None

🟦 <Moneys>→<OthNonAPRFees>

This element contains the sum of all <Fee> elements having AddToPrin set to true not occuring the date of an advance. If this element's value is zero, it will not show up in the results.

Attributes: None

🟦 <Moneys>→<ServiceChg>

This element represents all service charge <Fee> elements and contains the sum of all fees not occurring on an Advance and having AddToFinChg set to true. If this element's value is zero, it will not show up in the results.

Attributes: None

🟦 <Moneys>→<PocketFees>

This element holds the sum of all fees which are neither financed, nor added to the finance charge. In essence, they are paid out of the borrower’s pocket. If no out-of-pocket fees were requested, then this element will not show up in the XML output.

Attributes: None

🟦 <Moneys>→<MAPRFees>

This element holds the sum of all fees which are Military APR fees (including protection products), and will only appear if the Military APR has been requested.

Attributes: None

🟦 <Moneys>→<BalAdjusts>

The sum of all balance adjustments (see <BalAdj>) is reported in this element.

Attributes: None

🟦 <Moneys>→<ConInterest>

If the requested loan is a construction loan with a permanent loan attached and the account specified is set up to compute construction loans via the 'Simple' method, then this element will contain the construction interest for the requested loan.

Note that if a permanent loan is attached to a construction loan and the account is set up to use the 'LaserPro' method, then the construction and permanent loans are combined into a single loan, with the construction (and permanent) loan's interest being reflected in the <Interest> element, and both loans reflected in a single, combined amortization schedule.

If the requested loan was not a construction loan, or if construction loans have not been set up for the given account, then this element will not appear in the results.

Attributes: 🔸IsPrepaid

🔸 IsPrepaid

If the construction interest is disclosed as interest only payments in the amortization schedule, then the value of this attribute will be set to false. Otherwise, the value of this attribute will be set to true.

🟦 <Moneys>→<OddDaysPrepaid>

This element, if present, holds the total odd days prepaid finance charge. If no odd days prepaid fee was requested, then this element will not be present in the output.

Attributes: 🔹AddToPmt, 🔹DailyCost, 🔸OddDayCount, 🔹OddMonths

🔹 AddToPmt

If the odd days interest has been added to the first payment, this attribute will be present in the output with a value of true. If the odd days interest has been treated as a prepaid finance charge, then this attribute will not be present and a default value of false should be assumed.

🔹 DailyCost

If the odd days prepaid fee is computed using a rounded daily cost, then the value of this attribute will hold that value. If the odd days prepaid is not computed using a rounded daily cost, then this attribute will not be present.

🔸 OddDayCount

This attribute holds the number of odd days computed by the SCE for the requested loan.

🔹 OddMonths

This attribute holds the number of odd months computed by the SCE for the requested loan when using odd days accrual method 250.

🟦 <Moneys>→<MinIntChgAdj>

If a minimum interest charge was requested and the final payment was adjusted to meet this minimum interest charge, then this element will be returned in the response and will contain the value of the minimum finance charge adjustment.

Attributes: None

🟦 <Moneys>→<MinFinChgAdj>