Rationale:

This guidance stems from the application of the Separation of Concern principle and has several advantages. The most relevant from the point of financial modelers are as follows:

• 🔄 Enhances code reusability: Logic stored in a single Lambda function can be used for multiple purposes. For example, the same moving average calculation can be applied to both sales projections and gross margins without rewriting the code.
• 🔧 Easy to test, debug, and maintain: Since each Lambda does a specific task, it can be independently tested and can be debugged. Any correction in the logic of the Lambda will automatically be incorporated into all the wrapper LAMBDA that uses it.

Rationale:

• 🔍 Promotes transparency and simplifies debugging: Making all variables explicit in the Lambda ensures that calculations depend solely on the arguments (referential transparency), making testing and troubleshooting easier.

Note: Although referential transparency is critical in functional programming context, this guide does not mandate its strict adherence for Local Lambda, as it recognizes that such Local Lambda may be created with user convenience as its objective.

Rationale:

• 🔧 Supports flexible calculation layouts: Users can choose to arrange variables horizontally or vertically, and Lambda functions will operate reliably with either orientation.

Rationale:

• ⚡ Improves efficiency and easy to debug: In terms of performance, closed form solutions are the most efficient, followed by iterative solutions. Recursive Lambdas are the slowest among the three and may fail to perform when number of recursions exceed the limit. Ease of debugging follows the same order.

Rationale:

• ⚠️ Prevents conflicts and errors: If a variable name is same as a range name, then the range cannot be referred with the same name in the LET function. Further, when a range is given same name as a Lambda, the action will overwrite the Lambda leading to corruption in the model.

Rationale:

• 🔍 Improves clarity, and thus, auditability: Lambdas perform many calculations in-memory, where intermediate calculations will not be visible, and, thus, its workings are relatively difficult to understand. Proper documentation and in line comments offer clarity on what a code is meant to do. Such clarity also helps when auditing the function.
• ❌ Reduces misapplication of function: Documentation of the right use cases will help end users to correctly apply the appropriate function.

Rationale:

• 🛡️ Makes the models reliable: End users, often are likely to get the feeling of working with Black Box and may not be able to test its logic or accuracy. However, if the Lambda are pre-tested, it increases the reliability of the Lambda.

Rationale:

• 🔄 Allows refreshing and importing new Lambda: A central repository allows users to periodically import the updated list of Lambdas ensuring that the files have access to the latest set of approved Lambdas.

Rationale:

• 🔄 Ensures consistency and backward compatibility: Each Lambda maintains its functionality throughout all files, as any changes result in a new function. And reloading Global Lambdas from a central repository poses minimal risk to current calculations.
• 👥 Reduces dependency on individuals: New developers joining the team need not understand the inner workings of existing Lambdas, which ensures that future development will not suffer if original creators of the Lambda leave the organization.

Rationale:

• 🛡️ Retains reliability: Ensuring that a Global Lambda that has been validated is not modified retain the reliability of the said LAMBDA.

Rationale:

• ✅ Validates the output: There may be some bugs or flaws in what appears to be a logically accurate function. Validating it with scalar iterative approach will help uncover or rule out any such bugs.

Rationale:

• 🛡️ Tests model stability: This will help test whether the Lambda, and thus the overall model, can be stable under different situations.
• 🔧 Helps design error handling features: Such an edge case testing will help identify scenarios where the Lambda fails. The understanding can then be used to create error handling procedures within the same Lambda.
• 💪 Increases reliability: When a Lambda is able to handle the edge cases, it increases its reliability.

Rationale:

• 🔄 Increases coding consistency: Consistency in naming conventions, parameter order and error handling practices make it convenient for financial modelers to work with variety of Lambda.
• 📜 Formalises the best practices guidelines: Policies of the model governance will set clear binding guidelines on the best practices to follow for the organization.

Rationale:

• ✅ Ensures compliance with approved practices: The need for approval will reinforce the need to follow correct guidelines for the developer. Further, it also serves as a secondary check to detect and correct any gaps.

Rationale:

• 🎯 Clear accountability: Since creation and testing are with the same team, the Lambda creation team will have unambiguous accountability for producing correct Lambda.

Rationale:

• 🔒 Prevents proliferation of inconsistent or rogue functions: By ensuring that Lambdas are created by one central team ensures that a given Lambda used by the entire organization is the same.

Rationale:

• ✅ Applies quality control for third party Lambdas: Applying same level of quality checks and approval process for externally procured Lambda ensures that all the Lambda used in their models comply with the internal standards.

Rationale:

• 👀 Increases the chances of finding bugs: There is a higher chance of finding issues and bugs and finding them quickly if there are more eyes watching out for them.
• 🎯 Ensure single point responsibility for redressals and correction: Assigning redressal responsibility to the model governance team ensures clear accountability for the same.

Rationale:

• ⚙️ It needs careful execution: Retiring an existing Lambda is a far more complicated process as it is likely to affect several existing models and may even affect daily operations. Only the governance team can ensure a proper execution of the task.

Rationale:

• 🔄 Supports business continuity plan: Secured backups allow firms to quickly restore the repository should it get corrupt or lost for any reason.

Rationale:

• ⚠️ Assess risk of faulty Lambdas: Understanding the governance practices will help evaluate the risk of faulty Lambdas in the file. This will help plan the effort that needs to be applied for audit.

Rationale:

• 🎯 Helps evaluate contextual fit of Lambda: Documentation helps understand which Lambda should be used for which purpose, which will help understand whether application of a Lambda was correct in the given business context.

Rationale:

• 🛡️ Ensures that there are no unauthorized modifications to the Lambda: Reloading all the Lambda from the common repository eliminates the risk of any willful, or otherwise, modification of the authorized Lambda at the modeler’s end.

Rationale:

• 🛡️ Reduces the risk of rogue Lambdas: Referential transparency ensures that the output of the Lambda is not getting manipulated by any external factors.

Rationale:

• 🎭 Prevents intentional manipulation: Inappropriate default value for optional parameters is one of the ways to deceitfully manipulate the Lambda outcome.

AvgDSCRλ = LAMBDA(Cfads, Pmts, [guess],
    LET(_guess, IF(ISOMITTED(guess), 2.5, guess),
    D_2, AVERAGE(Cfads/Pmts),
    Return, D_2*Guess + _guess,
    Return)
)

Rationale:

• ⚡ It is faster and more reliable to confirm the correctness: Testing the Lambda on existing data allows audit firms to quickly establish whether the function works correctly as compared to reading through the entire logic and checking the working.

Rationale:

• 🔬 Helps validate a Lambda when proprietary data sets don’t exist: A validation utility, in the form of a separate calculation sheet, that allows users to drive down the calculation will help the auditors to validate Lambda output even if they do not have a proprietary data set to test.

Rationale:

• ⚙️ Ensure contextual application of logic: Lambdas are too abstract, and the Lambda name may not completely reveal the true purpose or the underlying logic. There is a risk that a Lambda meant for a different context is misapplied for another context. Thus, validating that the function called is indeed appropriate for the given context becomes critical.