OpenSourceRisk / Engine

Open Source Risk Engine
http://www.opensourcerisk.org
Other
484 stars 210 forks source link

Scripted trade does not generate past cashflows when value date is strictly after the last settlement date #253

Open quantthingy opened 1 month ago

quantthingy commented 1 month ago
true

how to reproduce:

result:

expected result:

I can provide an example if needed.

pcaspers commented 1 month ago

Hi! Just to be sure - are you setting

Both is necessary to get past cashflows in the report. The first flag controls the general filter on past cashflows and the second flag enables past cashflow info generation for scripted trades.

If you are using both flags already, could you kindly post an example to reproduce the issue? Thanks!

quantthingy commented 1 month ago

Both flags are included. Provided an example based on Example 52 from the release, using 1.8.12.1 version

Input and Output files are included.

Thanks for looking into it.

Archive.zip

pcaspers commented 1 month ago

The trade is considered "expired" in this case and therefore excluded from all reports.

I'll change the behavior so that the trade never expires if IncludePastCashflows is active for scripted trades. This change should appear on the master branch soon.

Please note that this change won't change the behavior of non-scripted trades which will still be excluded from the reporting if they are expired.

pcaspers commented 1 month ago

A few more notes:

There is a typo in the parameter name in ore.xml, it should be

    <Analytic type="cashflow">
...
      <Parameter name="includePastCashflows">true</Parameter>
    </Analytic>

The example script does not produce a cashflow. I changed

        <Number>
          <Name>GuaranteedFixings</Name>
          <Value>0</Value>
        </Number>

to get a flow for testing.

quantthingy commented 1 month ago

Thanks for the change.

Some brainstorming:

pcaspers commented 1 month ago
quantthingy commented 1 month ago

. Autocallable: I was referring to any Scripted trade with a Knock-out barrier. From a financial point of view, the expiry date is the Knock-Out date and not the the last potential Settlement date. This is the same logic for any barrier instrument.

in ored/portfolio/autocallable_01.hpp , the Trade Autocallable_01 is such an example

pcaspers commented 1 month ago

Yes, but if the autocallable is knocked out on a date d <= asof then it should not generate non-zero cf info after d?

On Wed, 10 Jul 2024 at 09:11, Julien Musset @.***> wrote:

. Autocallable: I was referring to any Scripted trade with a Knock-out barrier. From a financial point of view, the expiry date is the Knock-Out date and not the the last potential Settlement date. This is the same logic for any barrier instrument.

in ored/portfolio/autocallable_01.hpp , the Trade Autocallable_01 is such an example

— Reply to this email directly, view it on GitHub https://github.com/OpenSourceRisk/Engine/issues/253#issuecomment-2219728856, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAT4HLMP5DSJUZRVRUEJMODZLTNDNAVCNFSM6AAAAABKQECXHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJZG4ZDQOBVGY . You are receiving this because you commented.Message ID: @.***>

quantthingy commented 1 month ago

Agree. To be precise:

Assuming an autocallable with 3 autocall observation dates: 1 Jan 2023, 1 Feb 2022, 1 March 2022 If the autocall happened on 1 Feb 2022 (and therefore no cashflow on 1 March 2022), then I got the following in my test:

case 1: Value date on 15 Feb 2022: historical cashflow table generated at the instrument level case 2: Value date on 15 Mach 2022: no historical cashflow table generated at the instrument level

Your solution will solve this inconsistency.

(apology dont have an example to share, as all the test were in c++)

pcaspers commented 1 month ago

ok sounds good, we'll try to push out an update on master so that you can test the fix