diff --git a/cl/__init__.py b/cl/__init__.py
new file mode 100644
index 000000000..e69de29bb
diff --git a/cl/hackathon/BulkAnnotateSolution.csv b/cl/hackathon/BulkAnnotateSolution.csv
new file mode 100644
index 000000000..3407f3ac6
--- /dev/null
+++ b/cl/hackathon/BulkAnnotateSolution.csv
@@ -0,0 +1,105 @@
+solution_id,trade_group,trade_ids,llm,prompt
+GptBulkAnnotate,Preview,,gpt-4o-02,"You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {{
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ }},
+ {{
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ }},
+ {{
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ }},
+ {{
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ }},
+ {{
+ 'name': 'pay_leg_ccy',
+ 'description': 'Pay leg payment currency in 3-letter ISO-4217 format, for example USD or it could be a symbol like £. The currency is specified in 'We buy', 'We pay', 'Long', 'clients receive' or 'client receives'. Note this is not the currency for 'clients pay' or 'client pays'.'
+ }},
+ {{
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ }},
+ {{
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ }},
+ {{
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ }},
+ {{
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ }},
+ {{
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ }},
+ {{
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ }},
+ {{
+ 'name': 'rec_leg_ccy',
+ 'description': 'Receive leg payment currency in 3-letter ISO-4217 format, for example USD or it could be a symbol like £. The currency is specified in 'We sell', 'We receive', 'Short', 'clients pay' or 'client pay'. Note this is not the currency for 'clients receive' or 'client receives'. If it is not clear the subject then look for the subject from the previous sentence.'
+ }},
+ {{
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ }},
+ {{
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ }},
+ {{
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ }},
+ {{
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ }},
+ {{
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }}
+]
+'''
+
+Trade entry:
+'''
+{input_text}
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+"
+
diff --git a/cl/hackathon/HackathonInput.csv b/cl/hackathon/HackathonInput.csv
index 4870be79d..4af30d38e 100644
--- a/cl/hackathon/HackathonInput.csv
+++ b/cl/hackathon/HackathonInput.csv
@@ -1,8 +1,8 @@
trade_group,trade_id,entry_text
Preview,1,Sell 10y SOFR swap at 3.45%
Preview,2,"Notional: 10m
-Bank pays: 6M Term SOFR, semi-annual, act/360
-Bank receives: 3.45%, semi-annual, 30/360
+Client pays: 6M Term SOFR, semi-annual, act/360
+Client receives: 3.45%, semi-annual, 30/360
Start date: 10 November 2009
Tenor: 5y"
Preview,3,"USDEUR cross currency swap (fixed/fixed), 10 y maturity
diff --git a/cl/hackathon/bulk_annotate_solution.py b/cl/hackathon/bulk_annotate_solution.py
new file mode 100644
index 000000000..c257cd9a1
--- /dev/null
+++ b/cl/hackathon/bulk_annotate_solution.py
@@ -0,0 +1,373 @@
+# Copyright (C) 2023-present The Project Contributors
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+import traceback
+from dataclasses import dataclass, asdict
+from typing import Dict
+
+from cl.convince.retrievers.retriever_util import RetrieverUtil
+from cl.runtime import Context
+from cl.runtime.experiments.trial_key import TrialKey
+from cl.runtime.log.exceptions.user_error import UserError
+from cl.runtime.primitive.float_util import FloatUtil
+from cl.runtime.records.dataclasses_extensions import missing
+from cl.convince.llms.llm import Llm
+from cl.tradeentry.entries.amount_entry import AmountEntry
+from cl.tradeentry.entries.currency_entry import CurrencyEntry
+from cl.tradeentry.entries.date_entry import DateEntry
+from cl.tradeentry.entries.date_or_tenor_entry import DateOrTenorEntry
+from cl.tradeentry.entries.number_entry import NumberEntry
+from cl.hackathon.hackathon_output import HackathonOutput
+from cl.hackathon.hackathon_solution import HackathonSolution
+from cl.hackathon.bulk_annotate_utils import find_tags, maybe_convert
+from cl.tradeentry.entries.pay_freq_months_entry import PayFreqMonthsEntry
+from cl.tradeentry.trades.currency_key import CurrencyKey
+
+
+@dataclass(slots=True, kw_only=True)
+class BulkAnnotateSolution(HackathonSolution):
+ """Solution based on extracting values in one step."""
+
+ prompt: str = missing()
+ """One step prompt to parse trade."""
+
+ @staticmethod
+ def _extract_notional(extracted_notional: str | None) -> (float, str):
+ notional_amount = None
+ notional_currency = None
+ context = Context.current()
+
+ if extracted_notional:
+ notional = AmountEntry(text=extracted_notional)
+ notional.run_generate()
+
+ if notional_amount_entry_key := notional.amount:
+ notional_amount_entry = context.load_one(NumberEntry, notional_amount_entry_key)
+ notional_amount_entry.run_generate()
+ notional_amount = notional_amount_entry.value
+
+ if notional_currency_entry_key := notional.currency:
+ notional_currency_entry = context.load_one(CurrencyEntry, notional_currency_entry_key)
+
+ if notional_currency_entry_currency_key := notional_currency_entry.currency:
+ notional_currency_entry_currency = context.load_one(
+ CurrencyKey, notional_currency_entry_currency_key
+ )
+ notional_currency = notional_currency_entry_currency.iso_code
+
+ return notional_amount, notional_currency
+
+ def _leg_entry_to_dict(self, extracted_results: Dict[str, str], trade_description: str, leg_type: str) -> Dict:
+ retriever_error_message_prefix = (
+ f"Error trying to extract the field from the trade description\nTrade description: {trade_description}\n"
+ )
+
+ entry_error_message_template = (
+ "Error trying to process an extracted field from the trade description\n"
+ "Extracted field: {extracted_field}\n"
+ f"Trade description: {trade_description}\n"
+ "{exception_message}"
+ )
+
+ entry_dict = {}
+
+ # Payment Frequency
+ extracted_freq_months = extracted_results.get(leg_type + "_leg_freq_months", None)
+ if extracted_freq_months is not None:
+ try:
+ freq_months = PayFreqMonthsEntry(text=extracted_freq_months)
+ freq_months.run_generate()
+ entry_dict["freq_months"] = (
+ str(FloatUtil.to_int_or_float(v)) if (v := freq_months.pay_freq_months) else None
+ )
+ except Exception as e:
+ entry_dict["freq_months"] = entry_error_message_template.format(
+ extracted_field=extracted_freq_months, exception_message=str(e)
+ )
+
+ # Floating rate index
+ entry_dict["float_index"] = extracted_results.get(leg_type + "_leg_float_index", None)
+
+ # Floating rate spread
+ extracted_float_spread = extracted_results.get(leg_type + "_leg_float_spread_bp", None)
+ if extracted_float_spread is not None:
+ try:
+ if v:= maybe_convert(extracted_float_spread).isnumeric():
+ entry_dict["float_spread"] = v
+ else:
+ float_spread = NumberEntry(text=extracted_float_spread)
+ float_spread.run_generate()
+ entry_dict["float_spread"] = str(FloatUtil.to_int_or_float(v)) if (v := float_spread.value) else None
+ except Exception as e:
+ entry_dict["float_spread"] = entry_error_message_template.format(
+ extracted_field=extracted_float_spread, exception_message=str(e)
+ )
+
+ # Day-count Basis
+ entry_dict["basis"] = extracted_results.get(leg_type + "_leg_basis", None)
+
+ # Notional
+ extracted_notional = extracted_results.get(leg_type + "_leg_notional", None)
+ notional_amount, notional_currency = self._extract_notional(extracted_notional)
+ entry_dict["notional_amount"] = str(FloatUtil.to_int_or_float(v)) if (v := notional_amount) else None
+ entry_dict["notional_currency"] = notional_currency
+
+ # Currency
+ extracted_currency = extracted_results.get(leg_type + "_leg_ccy", None)
+ if extracted_currency is not None:
+ try:
+ currency = CurrencyEntry(text=extracted_currency)
+ currency.run_generate()
+ if notional_currency_entry_currency_key := currency.currency:
+ notional_currency_entry_currency = Context.current().load_one(
+ CurrencyKey, notional_currency_entry_currency_key
+ )
+ entry_dict["currency"] = notional_currency_entry_currency.iso_code
+ except Exception as e:
+ entry_dict["currency"] = entry_error_message_template.format(
+ extracted_field=extracted_currency, exception_message=str(e)
+ )
+
+ # Fixed Rate
+ extracted_fixed_rate = extracted_results.get(leg_type + "_leg_fixed_rate_pct", None)
+ if extracted_fixed_rate is not None:
+ extracted_fixed_rate = extracted_fixed_rate.lower().replace("%", "").replace("percent", "")
+ try:
+ fixed_rate = NumberEntry(text=extracted_fixed_rate)
+ fixed_rate.run_generate()
+ entry_dict["fixed_rate"] = str(FloatUtil.to_int_or_float(v)) if (v := fixed_rate.value) else None
+ except Exception as e:
+ entry_dict["fixed_rate"] = entry_error_message_template.format(
+ extracted_field=extracted_fixed_rate, exception_message=str(e)
+ )
+
+ return entry_dict
+
+ @staticmethod
+ def _retrieve_trade_parameters(extracted_results, input_description: str) -> Dict:
+ entry_error_message_template = (
+ "Error trying to process an extracted field from the trade description\n"
+ "Extracted field: {extracted_field}\n"
+ f"Trade description: {input_description}\n"
+ "{exception_message}"
+ )
+
+ trade_parameters = {}
+
+ # Maturity
+ extracted_maturity = extracted_results.get("maturity_date", None)
+ if extracted_maturity is not None:
+ try:
+ maturity = DateOrTenorEntry(text=extracted_maturity)
+ maturity.run_generate()
+ if date := maturity.date:
+ trade_parameters["maturity_date"] = date
+ else:
+ trade_parameters["tenor_years"] = (
+ str(FloatUtil.to_int_or_float(v)) if (v := maturity.years) else None
+ )
+ except Exception as e:
+ formatted_error_message = entry_error_message_template.format(
+ extracted_field=extracted_maturity, exception_message=str(e)
+ )
+ trade_parameters["maturity_date"] = formatted_error_message
+
+ # tenor
+ extracted_tenor = extracted_results.get("tenor_years", None)
+ if extracted_tenor is not None:
+ extracted_tenor = "".join([i for i in extracted_tenor if i.isnumeric()]) + "y"
+
+ try:
+ tenor = DateOrTenorEntry(text=extracted_tenor)
+ tenor.run_generate()
+ if years := tenor.years:
+ trade_parameters["tenor_years"] = str(FloatUtil.to_int_or_float(years))
+ except Exception as e:
+ formatted_error_message = entry_error_message_template.format(
+ extracted_field=extracted_maturity, exception_message=str(e)
+ )
+ trade_parameters["tenor_years"] = formatted_error_message
+
+ # Effective date
+ extracted_effective_date = extracted_results.get("effective_date", None)
+ if extracted_effective_date is not None:
+ try:
+ effective_date = DateEntry(text=extracted_effective_date)
+ effective_date.run_generate()
+ if date := effective_date.date:
+ trade_parameters["effective_date"] = date
+ except Exception as e:
+ trade_parameters["effective_date"] = entry_error_message_template.format(
+ extracted_field=extracted_effective_date, exception_message=str(e)
+ )
+
+ return trade_parameters
+
+ def score_output(self, output_: HackathonOutput) -> None:
+ try:
+ direction_prompt = """
+ For the following trade entry, your task is to determine the direction one of 'Normal' or 'Reversed'
+ 'Normal' means money is moving from the Client to the Bank (we/us)
+ 'Reversed' means money is moving from the Bank (we/us) to the Client
+
+ E.g:
+ Client Buys: 'Normal'
+ Client Sells: 'Reversed'
+ We Buy: 'Reversed'
+ We Sell: 'Normal'
+ Client to pay: 'Normal'
+ Bank to pay: 'Reversed'
+
+ Here is the trade entry:
+ ```
+ {trade}
+ ```
+ Respond in as few words as possible, end your response with either 'Normal' or 'Reversed'.
+ If unsure, return 'Normal'.
+ """.strip()
+
+ if Context.current().trial is not None:
+ raise UserError("Cannot override TrialId that is already set, exiting.")
+
+ with Context(full_llm=self.llm, trial=TrialKey(trial_id=str(output_.trial_id))) as context:
+ print("*" * 20 + "original" + "*" * 20)
+ print(output_.entry_text)
+
+ # Load the full LLM specified by the context
+ llm = context.load_one(Llm, context.full_llm)
+ query = self.prompt.format(input_text=output_.entry_text)
+
+ # output = llm.completion(direction_prompt.format(trade=output_.entry_text))
+ # direction = "reversed" not in output.lower()
+ # print("*"*20 + "direction" + "*"*20)
+ # print(output)
+ # print(direction)
+ direction = True # directionality makes it worse
+
+ output = llm.completion(query)
+
+ print("*" * 20 + "tagged" + "*" * 20)
+ print(output)
+ # Find the substring in the original text that matches the tagged region
+ # Includes error correction
+ json_output = find_tags(output_.entry_text, output)
+ # this format supports multiple results for each field, fix it:
+ extracted_results = {k: v[0] for k, v in json_output.items()}
+
+ if not extracted_results:
+ print("*" * 20 + "json fallback" + "*" * 20)
+ try:
+ # maybe the model returned json
+ extracted_results = RetrieverUtil.extract_json(output)
+ except:
+ pass
+
+ print("*" * 20 + "extracted" + "*" * 20)
+ print(extracted_results)
+ self.build_output(output_, direction, extracted_results, {})
+
+ found = {}
+ for k, v in asdict(output_).items():
+ if k in extracted_results:
+ if v is not None:
+ if not isinstance(v, str):
+ found[k] = v
+ elif "error" not in v.lower():
+ found[k] = v
+
+ retry = {}
+ for k, v in extracted_results.items():
+ if v is not None:
+ if k not in found:
+ retry[k] = maybe_convert(v)
+
+ if retry:
+ print("*" * 20 + "retrying" + "*" * 20)
+ print(retry)
+ self.build_output(output_, direction, retry, found)
+
+ print("*" * 20 + "done" + "*" * 20)
+
+ except:
+ traceback.print_exc()
+
+ def build_output(self, output_, direction, extracted_results, found_dict):
+ trade_parameters = self._retrieve_trade_parameters(extracted_results, output_.entry_text)
+ if "maturity_date" not in found_dict:
+ output_.maturity_date = trade_parameters.get("maturity_date")
+ if "tenor_years" not in found_dict:
+ output_.tenor_years = trade_parameters.get("tenor_years")
+ if "effective_date" not in found_dict:
+ output_.effective_date = trade_parameters.get("effective_date")
+
+ if direction:
+ leg_type = "pay"
+ else:
+ leg_type = "rec"
+ # Populate pay leg
+ pay_leg_parameters = self._leg_entry_to_dict(extracted_results, output_.entry_text, leg_type)
+
+ if "pay_leg_notional" not in found_dict:
+ output_.pay_leg_notional = pay_leg_parameters.get("notional_amount")
+
+ if "pay_leg_basis" not in found_dict:
+ output_.pay_leg_basis = pay_leg_parameters.get("basis")
+ if "pay_leg_freq_months" not in found_dict:
+ output_.pay_leg_freq_months = pay_leg_parameters.get("freq_months")
+ if "pay_leg_float_index" not in found_dict:
+ output_.pay_leg_float_index = pay_leg_parameters.get("float_index")
+ if "pay_leg_float_spread_bp" not in found_dict:
+ output_.pay_leg_float_spread_bp = pay_leg_parameters.get("float_spread")
+ if "pay_leg_fixed_rate_pct" not in found_dict:
+ output_.pay_leg_fixed_rate_pct = pay_leg_parameters.get("fixed_rate")
+ if "pay_leg_ccy " not in found_dict: # Changed key to "pay_leg_currency" for consistency
+ output_.pay_leg_ccy = pay_leg_parameters.get("currency")
+
+ if direction:
+ leg_type = "rec"
+ else:
+ leg_type = "pay"
+
+ # Populate receive leg
+ rec_leg_parameters = self._leg_entry_to_dict(extracted_results, output_.entry_text, leg_type)
+ if "rec_leg_notional" not in found_dict:
+ output_.rec_leg_notional = rec_leg_parameters.get("notional_amount")
+
+ if "rec_leg_basis" not in found_dict:
+ output_.rec_leg_basis = rec_leg_parameters.get("basis")
+ if "rec_leg_freq_months" not in found_dict:
+ output_.rec_leg_freq_months = rec_leg_parameters.get("freq_months")
+ if "rec_leg_float_index" not in found_dict:
+ output_.rec_leg_float_index = rec_leg_parameters.get("float_index")
+ if "rec_leg_float_spread_bp" not in found_dict:
+ output_.rec_leg_float_spread_bp = rec_leg_parameters.get("float_spread")
+ if "rec_leg_fixed_rate_pct" not in found_dict:
+ output_.rec_leg_fixed_rate_pct = rec_leg_parameters.get("fixed_rate")
+ if "rec_leg_ccy " not in found_dict: # Changed key to "rec_leg_currency" for consistency
+ output_.rec_leg_ccy = rec_leg_parameters.get("currency")
+
+ # post processing:
+ if "pay_leg_notional" not in found_dict:
+ if output_.pay_leg_notional and not output_.rec_leg_freq_months:
+ output_.rec_leg_notional = output_.pay_leg_notional
+
+ if output_.rec_leg_notional and not output_.pay_leg_notional:
+ output_.pay_leg_notional = output_.rec_leg_notional
+
+ # if "pay_leg_freq_months" not in found_dict:
+ # if output_.pay_leg_freq_months and not output_.rec_leg_freq_months:
+ # output_.rec_leg_notional = output_.pay_leg_freq_months
+ #
+ # if output_.rec_leg_freq_months and not output_.pay_leg_freq_months:
+ # output_.pay_leg_freq_months = output_.rec_leg_freq_months
diff --git a/cl/hackathon/bulk_annotate_utils.py b/cl/hackathon/bulk_annotate_utils.py
new file mode 100644
index 000000000..c034f996c
--- /dev/null
+++ b/cl/hackathon/bulk_annotate_utils.py
@@ -0,0 +1,169 @@
+try:
+ from Levenshtein import editops
+except {ImportError, ModuleNotFoundError}:
+ editops = None
+
+import re
+import text_to_num
+
+
+def re2dict(m, start=None):
+ offset = start["start"] if start else 0
+ if m is None:
+ return {}
+ out = {
+ "tag": m.group("tag"),
+ "start": m.start() + offset,
+ "end": m.end() + offset}
+ out['idx'] = out['start']
+ return out
+
+
+def find_tags(original, tagged):
+ tag_start = r"<(?P[^/]+?)>"
+ tag_end = r".+?)>"
+ tag_end_f = r"{tag})>"
+
+ tag_starts = []
+ tag_ends = []
+
+ for start in re.finditer(tag_start, tagged, re.I):
+ s = re2dict(start)
+ tmp_end = tag_end_f.format(tag=start.group("tag"))
+ end = re.search(tmp_end, tagged[start.start():], re.I)
+ e = re2dict(end, s)
+ if e:
+ tag_starts.append(s)
+ tag_ends.append(e)
+
+ rebuilt = re.sub(tag_end, "", re.sub(tag_start, "", tagged))
+
+ ops = {idx: op for op, _, idx in editops(original, rebuilt)}
+
+ tag_offset = 0
+ for idx in range(len(tagged)):
+ in_tag = False
+ for start, end in zip(tag_starts, tag_ends):
+ if start["start"] <= idx < start["end"]:
+ in_tag = True
+ elif end["start"] <= idx < end["end"]:
+ in_tag = True
+
+ if in_tag:
+ tag_offset -= 1
+ for start, end in zip(tag_starts, tag_ends):
+ if start["start"] > idx:
+ start['idx'] -= 1
+ if end["start"] > idx:
+ end['idx'] -= 1
+
+ elif idx + tag_offset in ops:
+ op = ops.pop(idx + tag_offset)
+ if op == "insert":
+ for start, end in zip(tag_starts, tag_ends):
+ if start["start"] > idx:
+ start['idx'] -= 1
+ if end["start"] > idx:
+ end['idx'] -= 1
+
+ elif op == "delete":
+ for start, end in zip(tag_starts, tag_ends):
+ if start["start"] > idx:
+ start['idx'] += 1
+ if end["start"] > idx:
+ end['idx'] += 1
+ idx += 1
+
+ found_tags = {}
+ for start, end in zip(tag_starts, tag_ends):
+ found_tags.setdefault(start['tag'], [])
+ tmp = original[start['idx']:end['idx']]
+ found_tags[start['tag']].append(tmp)
+
+ return found_tags
+
+
+def py_editops(*args):
+ if len(args) == 2:
+ source_string, destination_string = args
+ return _editops_from_strings(source_string, destination_string)
+ elif len(args) == 3:
+ edit_operations, source_length, destination_length = args
+ return _editops_from_opcodes(edit_operations, source_length, destination_length)
+ else:
+ raise ValueError("Invalid number of arguments")
+
+def _editops_from_strings(source, dest):
+ m, n = len(source), len(dest)
+ dp = [[0] * (n + 1) for _ in range(m + 1)]
+
+ for i in range(m + 1):
+ for j in range(n + 1):
+ if i == 0:
+ dp[i][j] = j # Insertions
+ elif j == 0:
+ dp[i][j] = i # Deletions
+ elif source[i - 1] == dest[j - 1]:
+ dp[i][j] = dp[i - 1][j - 1] # No change
+ else:
+ dp[i][j] = 1 + min(
+ dp[i - 1][j], # Deletion
+ dp[i][j - 1], # Insertion
+ dp[i - 1][j - 1] # Replacement
+ )
+
+ # Reconstruct the edit operations
+ operations = []
+ i, j = m, n
+ while i > 0 or j > 0:
+ if i > 0 and j > 0 and source[i - 1] == dest[j - 1]:
+ i -= 1
+ j -= 1
+ elif j > 0 and (i == 0 or dp[i][j] == dp[i][j - 1] + 1):
+ operations.append(('insert', i, j - 1))
+ j -= 1
+ elif i > 0 and (j == 0 or dp[i][j] == dp[i - 1][j] + 1):
+ operations.append(('delete', i - 1, j))
+ i -= 1
+ else:
+ operations.append(('replace', i - 1, j - 1))
+ i -= 1
+ j -= 1
+
+ # Reverse to get the correct order
+ operations.reverse()
+ return operations
+
+def _editops_from_opcodes(opcodes, source_length, destination_length):
+ operations = []
+ for op in opcodes:
+ operation, spos, dpos = op
+ operations.append((operation, spos, dpos))
+ return operations
+
+# If the library is not available then use the slower python one (AI generated, results not guaranteed)
+if editops is None:
+ editops = py_editops
+
+
+def maybe_convert(x):
+ edits = {
+ "point": ".",
+ }
+ checked = []
+ for word in x.split(" "):
+ if word in edits:
+ checked.append(edits[word])
+ else:
+ try:
+ word = text_to_num.text2num(word, "en")
+ checked.append(str(word))
+ except:
+ pass
+ try:
+ return str(int("".join(checked)))
+ except:
+ try:
+ return str(float("".join(checked)))
+ except:
+ return x
\ No newline at end of file
diff --git a/completions/gpt-4o.completions.csv b/completions/gpt-4o.completions.csv
index dcc3c393b..0696f5e84 100644
--- a/completions/gpt-4o.completions.csv
+++ b/completions/gpt-4o.completions.csv
@@ -1665,3 +1665,25496 @@ Examples:
""justification"": ""The input text 'd'euros' refers to euros, and the ISO-4217 currency code for Euros is 'EUR', which is one of the valid choices.""
}
```"
+2024-11-18-11-49-56-762-75c0ac261c60d600f20a,"TrialID: 0
+You will be provided with a trade entry and a list with parameter descriptions.
+Your task is try to find every parameter from the list and return it in the correct format specified in the parameter description.
+
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise extract the parameter by copying its value form the text.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date in ISO-8601 yyyy-mm-dd format (omit if not specified).'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date in ISO-8601 yyyy-mm-dd string format (omit if not specified).'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in whole years, for example 10 for a 10-year swap (omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, without currency.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': 'Pay leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45 (omit for a floating leg).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount, for example 10000000.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'Receive leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate in percent (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell 10y SOFR swap at 3.45%
+'''
+
+You must return the original trade entry with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%","```plaintext
+Sell 10y SOFR swap at 3.45%
+```"
+2024-11-18-11-49-58-128-74c1ba1e6cde3617fa4f,"TrialID: 0
+You will be provided with a trade entry and a list with parameter descriptions.
+Your task is try to find every parameter from the list and return it in the correct format specified in the parameter description.
+
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise extract the parameter by copying its value form the text.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date in ISO-8601 yyyy-mm-dd format (omit if not specified).'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date in ISO-8601 yyyy-mm-dd string format (omit if not specified).'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in whole years, for example 10 for a 10-year swap (omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, without currency.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': 'Pay leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45 (omit for a floating leg).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount, for example 10000000.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'Receive leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate in percent (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Notional: 10m
+Client pays: 6M Term SOFR, semi-annual, act/360
+Client receives: 3.45%, semi-annual, 30/360
+Start date: 10 November 2009
+Tenor: 5y
+'''
+
+You must return the original trade entry with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%","```xml
+Notional: 10m
+Client pays: 6M Term SOFR, 6, act/360
+Client receives: 3.45%, 6, 30/360
+Start date: 2009-11-10
+5
+```"
+2024-11-18-12-28-53-774-7432832e2429870f9593,"TrialID: 0
+You will be provided with a trade entry and a list with parameter descriptions.
+Your task is try to find every parameter from the list and return it in the correct format specified in the parameter description.
+
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise extract the parameter by copying its value form the text.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date in ISO-8601 yyyy-mm-dd format (omit if not specified).'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date in ISO-8601 yyyy-mm-dd string format (omit if not specified).'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in whole years, for example 10 for a 10-year swap (omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, without currency.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': 'Pay leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45 (omit for a floating leg).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount, for example 10000000.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'Receive leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate in percent (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell 10y SOFR swap at 3.45%
+'''
+
+Return the output in specified JSON format
+{
+ :
+}","```json
+{
+ ""tenor_years"": 10,
+ ""pay_leg_fixed_rate_pct"": 3.45
+}
+```"
+2024-11-18-12-28-54-700-7dc2a734865a30c55a38,"TrialID: 0
+You will be provided with a trade entry and a list with parameter descriptions.
+Your task is try to find every parameter from the list and return it in the correct format specified in the parameter description.
+
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise extract the parameter by copying its value form the text.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date in ISO-8601 yyyy-mm-dd format (omit if not specified).'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date in ISO-8601 yyyy-mm-dd string format (omit if not specified).'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in whole years, for example 10 for a 10-year swap (omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, without currency.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': 'Pay leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45 (omit for a floating leg).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount, for example 10000000.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'Receive leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate in percent (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Notional: 10m
+Client pays: 6M Term SOFR, semi-annual, act/360
+Client receives: 3.45%, semi-annual, 30/360
+Start date: 10 November 2009
+Tenor: 5y
+'''
+
+Return the output in specified JSON format
+{
+ :
+}","To extract the parameters from the trade entry based on the provided descriptions, let's analyze the details in the trade entry:
+
+- **Notional**: 10m
+- **Client pays**: 6M Term SOFR, semi-annual, act/360
+- **Client receives**: 3.45%, semi-annual, 30/360
+- **Start date**: 10 November 2009
+- **Tenor**: 5y
+
+From this, we can identify the following parameters:
+
+1. **effective_date**: ""Start date: 10 November 2009"" translates to 2009-11-10 in ISO format.
+2. **tenor_years**: ""Tenor: 5y"" indicates a tenor of 5 years.
+3. **pay_leg_notional** and **rec_leg_notional**: The notional is typically the same for pay and receive legs unless otherwise specified. ""Notional: 10m"" means 10000000.
+4. **pay_leg_float_index**: ""Client pays: 6M Term SOFR"" indicates the pay leg is floating with index ""6M Term SOFR"".
+5. **pay_leg_freq_months**: ""semi-annual"" implies a payment frequency of 6 months.
+6. **pay_leg_basis**: ""act/360"" is the daycount basis for the pay leg.
+7. **pay_leg_float_spread_bp**: The pay leg is floating based on ""6M Term SOFR"", and there is no specified spread, implying it is ""0"" or omitted.
+8. **rec_leg_fixed_rate_pct**: ""Client receives: 3.45%"" directly states the fixed rate.
+9. **rec_leg_freq_months**: ""semi-annual"" also refers to the receive leg, implying a 6-month frequency.
+10. **rec_leg_basis**: ""30/360"" is the daycount basis for the receive leg.
+11. **rec_leg_ccy** and **pay_leg_ccy**: The currency isn't specified in the trade entry, so leave these out.
+
+Given these identifications, the JSON output format should be:
+
+```json
+{
+ ""effective_date"": ""2009-11-10"",
+ ""tenor_years"": 5,
+ ""pay_leg_notional"": 10000000,
+ ""rec_leg_notional"": 10000000,
+ ""pay_leg_freq_months"": 6,
+ ""pay_leg_basis"": ""act/360"",
+ ""pay_leg_float_index"": ""6M Term SOFR"",
+ ""rec_leg_fixed_rate_pct"": 3.45,
+ ""rec_leg_freq_months"": 6,
+ ""rec_leg_basis"": ""30/360""
+}
+```
+
+Parameters not mentioned in the trade entry (such as maturity date, currencies) or with no additional details specified are omitted as instructed."
+2024-11-18-14-25-47-333-7e03b31ddbe711191d18,"TrialID: 0
+You will be provided with a trade entry and a list with parameter descriptions.
+Your task is try to find every parameter from the list and return it in the correct format specified in the parameter description.
+
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise extract the parameter by copying its value form the text.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date in ISO-8601 yyyy-mm-dd format (omit if not specified).'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date in ISO-8601 yyyy-mm-dd string format (omit if not specified).'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in whole years, for example 10 for a 10-year swap (omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, without currency.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': 'Pay leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45 (omit for a floating leg).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount, for example 10000000.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'Receive leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate in percent (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Executed trade receiving 4.50% fixed vs 1-month SOFR on $100mm notional, 2-year tenor, starting December 20th, 2023
+'''
+
+Return the output in specified JSON format
+{
+ :
+}","```json
+{
+ ""effective_date"": ""2023-12-20"",
+ ""tenor_years"": 2,
+ ""pay_leg_float_index"": ""1-month SOFR"",
+ ""rec_leg_notional"": ""100000000"",
+ ""rec_leg_fixed_rate_pct"": 4.50
+}
+```"
+2024-11-18-14-25-49-974-7bd0975876053d5cc92a,"TrialID: 0
+You will be provided with a trade entry and a list with parameter descriptions.
+Your task is try to find every parameter from the list and return it in the correct format specified in the parameter description.
+
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise extract the parameter by copying its value form the text.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date in ISO-8601 yyyy-mm-dd format (omit if not specified).'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date in ISO-8601 yyyy-mm-dd string format (omit if not specified).'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in whole years, for example 10 for a 10-year swap (omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, without currency.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': 'Pay leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45 (omit for a floating leg).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount, for example 10000000.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'Receive leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate in percent (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Paying USD, receiving JPY, 2-year tenor, plus 32bps spread, ¥5bn notional
+'''
+
+Return the output in specified JSON format
+{
+ :
+}","Here is the extracted data from the trade entry according to the given parameter descriptions:
+
+```json
+{
+ ""tenor_years"": ""2"",
+ ""pay_leg_ccy"": ""USD"",
+ ""rec_leg_ccy"": ""JPY"",
+ ""rec_leg_float_spread_bp"": ""32"",
+ ""rec_leg_notional"": ""5000000000""
+}
+```"
+2024-11-18-14-25-51-572-7211972322a2019f7e75,"TrialID: 0
+You will be provided with a trade entry and a list with parameter descriptions.
+Your task is try to find every parameter from the list and return it in the correct format specified in the parameter description.
+
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise extract the parameter by copying its value form the text.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date in ISO-8601 yyyy-mm-dd format (omit if not specified).'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date in ISO-8601 yyyy-mm-dd string format (omit if not specified).'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in whole years, for example 10 for a 10-year swap (omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, without currency.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': 'Pay leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45 (omit for a floating leg).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount, for example 10000000.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'Receive leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate in percent (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Executed 2-year basis swap
+Paying EUR, receiving USD plus 85 basis points
+100mm notional
+'''
+
+Return the output in specified JSON format
+{
+ :
+}","```json
+{
+ ""tenor_years"": ""2"",
+ ""pay_leg_ccy"": ""EUR"",
+ ""rec_leg_ccy"": ""USD"",
+ ""rec_leg_float_spread_bp"": ""85"",
+ ""pay_leg_notional"": ""100mm"",
+ ""rec_leg_notional"": ""100mm""
+}
+```"
+2024-11-18-14-25-53-582-7ee0b0a3de638b2e3ef7,"TrialID: 0
+You will be provided with a trade entry and a list with parameter descriptions.
+Your task is try to find every parameter from the list and return it in the correct format specified in the parameter description.
+
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise extract the parameter by copying its value form the text.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date in ISO-8601 yyyy-mm-dd format (omit if not specified).'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date in ISO-8601 yyyy-mm-dd string format (omit if not specified).'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in whole years, for example 10 for a 10-year swap (omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, without currency.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': 'Pay leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45 (omit for a floating leg).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount, for example 10000000.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'Receive leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate in percent (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+USDEUR cross currency swap (fixed/fixed), 10 y maturity
+Client pays 2.3% USD, we pay 1.7% EUR
+'''
+
+Return the output in specified JSON format
+{
+ :
+}","```json
+{
+ ""tenor_years"": ""10"",
+ ""pay_leg_fixed_rate_pct"": ""2.3"",
+ ""pay_leg_ccy"": ""USD"",
+ ""rec_leg_fixed_rate_pct"": ""1.7"",
+ ""rec_leg_ccy"": ""EUR""
+}
+```"
+2024-11-18-14-25-55-315-7cd3a7b20ffed95474e9,"TrialID: 0
+You will be provided with a trade entry and a list with parameter descriptions.
+Your task is try to find every parameter from the list and return it in the correct format specified in the parameter description.
+
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise extract the parameter by copying its value form the text.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date in ISO-8601 yyyy-mm-dd format (omit if not specified).'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date in ISO-8601 yyyy-mm-dd string format (omit if not specified).'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in whole years, for example 10 for a 10-year swap (omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, without currency.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': 'Pay leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45 (omit for a floating leg).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount, for example 10000000.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'Receive leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate in percent (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+EURUSD cross currency swap (fix fix) with 5y tenor where client pays EUR 6% coupon, receives USD 7.5%
+Both legs are semiannual and 30/360
+'''
+
+Return the output in specified JSON format
+{
+ :
+}","```json
+{
+ ""tenor_years"": 5,
+ ""pay_leg_notional"": ""EUR"",
+ ""pay_leg_ccy"": ""EUR"",
+ ""pay_leg_freq_months"": 6,
+ ""pay_leg_basis"": ""30/360"",
+ ""pay_leg_fixed_rate_pct"": 6,
+ ""rec_leg_notional"": ""USD"",
+ ""rec_leg_ccy"": ""USD"",
+ ""rec_leg_freq_months"": 6,
+ ""rec_leg_basis"": ""30/360"",
+ ""rec_leg_fixed_rate_pct"": 7.5
+}
+```"
+2024-11-18-14-26-01-875-7ca0928ad739879c593e,"TrialID: 0
+You will be provided with a trade entry and a list with parameter descriptions.
+Your task is try to find every parameter from the list and return it in the correct format specified in the parameter description.
+
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise extract the parameter by copying its value form the text.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date in ISO-8601 yyyy-mm-dd format (omit if not specified).'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date in ISO-8601 yyyy-mm-dd string format (omit if not specified).'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in whole years, for example 10 for a 10-year swap (omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, without currency.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': 'Pay leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45 (omit for a floating leg).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount, for example 10000000.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'Receive leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate in percent (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+I have trade details
+Profile: USD Interest rate swap
+Tenor: 10 years, both legs quarterly
+We pay USD fixed 3.35%, client pays SOFR
+'''
+
+Return the output in specified JSON format
+{
+ :
+}","```json
+{
+ ""tenor_years"": ""10"",
+ ""pay_leg_fixed_rate_pct"": ""3.35"",
+ ""rec_leg_float_index"": ""SOFR""
+}
+```"
+2024-11-18-14-26-03-147-7630ad0926de9ad9a270,"TrialID: 0
+You will be provided with a trade entry and a list with parameter descriptions.
+Your task is try to find every parameter from the list and return it in the correct format specified in the parameter description.
+
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise extract the parameter by copying its value form the text.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date in ISO-8601 yyyy-mm-dd format (omit if not specified).'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date in ISO-8601 yyyy-mm-dd string format (omit if not specified).'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in whole years, for example 10 for a 10-year swap (omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, without currency.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': 'Pay leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45 (omit for a floating leg).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount, for example 10000000.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'Receive leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate in percent (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell SOFR swap at three point five percent, maturity November 18, 2027
+'''
+
+Return the output in specified JSON format
+{
+ :
+}","```json
+{
+ ""maturity_date"": ""2027-11-18"",
+ ""pay_leg_fixed_rate_pct"": ""3.5"",
+ ""rec_leg_float_index"": ""SOFR""
+}
+```"
+2024-11-18-14-26-04-027-74819933c0eefc9f70e4,"TrialID: 0
+You will be provided with a trade entry and a list with parameter descriptions.
+Your task is try to find every parameter from the list and return it in the correct format specified in the parameter description.
+
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise extract the parameter by copying its value form the text.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date in ISO-8601 yyyy-mm-dd format (omit if not specified).'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date in ISO-8601 yyyy-mm-dd string format (omit if not specified).'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in whole years, for example 10 for a 10-year swap (omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, without currency.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': 'Pay leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45 (omit for a floating leg).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount, for example 10000000.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'Receive leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate in percent (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+SOFR swap, we receive fixed, 10y tenor starting on Nov 19, 2024
+'''
+
+Return the output in specified JSON format
+{
+ :
+}","```json
+{
+ ""tenor_years"": ""10"",
+ ""effective_date"": ""2024-11-19""
+}
+```"
+2024-11-18-14-26-05-727-74a3b1a4dc09b577e27a,"TrialID: 0
+You will be provided with a trade entry and a list with parameter descriptions.
+Your task is try to find every parameter from the list and return it in the correct format specified in the parameter description.
+
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise extract the parameter by copying its value form the text.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date in ISO-8601 yyyy-mm-dd format (omit if not specified).'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date in ISO-8601 yyyy-mm-dd string format (omit if not specified).'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in whole years, for example 10 for a 10-year swap (omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, without currency.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': 'Pay leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45 (omit for a floating leg).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount, for example 10000000.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'Receive leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate in percent (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Vanilla swap at 2.90%, we pay fixed, 10y maturity
+'''
+
+Return the output in specified JSON format
+{
+ :
+}","```json
+{
+ ""tenor_years"": ""10"",
+ ""pay_leg_fixed_rate_pct"": ""2.90""
+}
+```"
+2024-11-18-14-26-06-778-7aa1b7aa1481aec1bc0d,"TrialID: 0
+You will be provided with a trade entry and a list with parameter descriptions.
+Your task is try to find every parameter from the list and return it in the correct format specified in the parameter description.
+
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise extract the parameter by copying its value form the text.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date in ISO-8601 yyyy-mm-dd format (omit if not specified).'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date in ISO-8601 yyyy-mm-dd string format (omit if not specified).'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in whole years, for example 10 for a 10-year swap (omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, without currency.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': 'Pay leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45 (omit for a floating leg).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount, for example 10000000.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'Receive leg payment currency in 3-letter ISO-4217 format, for example USD.'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Pay leg daycount basis as specified, for example act/360.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR (omit for a fixed leg).'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate in percent (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+We receive 3.5 on 10-year swap, will pay SOFR plus twenty basis points, effective November 18, 2024
+'''
+
+Return the output in specified JSON format
+{
+ :
+}","```json
+{
+ ""effective_date"": ""2024-11-18"",
+ ""tenor_years"": 10,
+ ""pay_leg_float_index"": ""SOFR"",
+ ""pay_leg_float_spread_bp"": 20,
+ ""rec_leg_fixed_rate_pct"": 3.5
+}
+```"
+2024-11-18-17-08-51-495-7472be292f20e305ceff,"TrialID: 0
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell 10y SOFR swap at 3.45%
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10y SOFR swap at 3.45%
+2024-11-18-17-08-53-253-7843a218eed95ea44707,"TrialID: 0
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Executed trade receiving 4.50% fixed vs 1-month SOFR on $100mm notional, 2-year tenor, starting December 20th, 2023
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%4.50% fixed vs 1-month SOFR on $100mm notional, 2-year tenor, starting December 20th, 2023"
+2024-11-18-17-08-54-737-7890afd2c5ef9f6df948,"TrialID: 0
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```USD100mm```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""```{USD}100mm```"",
+ ""justification"": ""The input text contains 'USD', which matches one of the semicolon-delimited examples for the parameter. 'USD' is an ISO-4217 code for currency.""
+}
+```"
+2024-11-18-17-08-57-823-72b3995f071b6ec74351,"TrialID: 0
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```USD100mm```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""USD{100mm}"",
+ ""justification"": ""The input text 'USD100mm' contains the numerical value '100' followed by the scale unit 'mm', which is an abbreviated form for millions. The instructions specify to exclude currency symbols such as 'USD' but include the numerical value and scale units, hence '100mm' is correctly identified and surrounded with curly braces.""
+}
+```"
+2024-11-18-17-08-59-297-75028719774a8b551bee,"TrialID: 0
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Paying USD, receiving JPY, 2-year tenor, plus 32bps spread, ¥5bn notional
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%USD, receiving JPY, 2-year tenor, plus 32bps spread, ¥5bn notional
+```"
+2024-11-18-17-09-00-890-7a91af0486b897e32e65,"TrialID: 0
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```USD```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""USD"",
+ ""justification"": ""The input text 'USD' is an exact match to one of the provided valid choices, which is the ISO-4217 currency code for United States Dollar in the correct format of three uppercase letters.""
+}
+```"
+2024-11-18-17-09-02-532-7611ac06e2eef47fb1be,"TrialID: 0
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```5bn```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text '5bn' does not contain any symbols, words, or codes that match the description of a currency symbol, natural language description, or ISO-4217 code.""
+}
+```"
+2024-11-18-17-09-03-600-73d2a37c08676e8f1b19,"TrialID: 0
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```5bn```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{5bn}"",
+ ""justification"": ""The input text '5bn' contains a numerical value '5' followed by a scale unit 'bn' which stands for billions. The entire string '5bn' represents an amount and is surrounded by curly braces as it conforms to the parameter description.""
+}
+```"
+2024-11-18-17-09-04-931-7d42b03b5f88fc53911c,"TrialID: 0
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```JPY```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""JPY"",
+ ""justification"": ""The input text 'JPY' exactly matches one of the valid choices 'JPY'. It adheres to the ISO-4217 format required for the currency code and is within the provided list of valid choices.""
+}
+```"
+2024-11-18-17-09-06-223-76b1ac863a46635cf9a7,"TrialID: 0
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Executed 2-year basis swap
+Paying EUR, receiving USD plus 85 basis points
+100mm notional
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%2-year basis swap
+Paying EUR, receiving USD plus 85 basis points
+100mm notional"
+2024-11-18-17-09-07-691-7081bd2ce2ae8107b32b,"TrialID: 0
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```100mm```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text '100mm' does not contain information related to a currency symbol, natural language description, or ISO-4217 code. It appears to be a measurement unit rather than a currency reference.""
+}
+```"
+2024-11-18-17-09-09-043-7ea2aec4e1272c9f5a0d,"TrialID: 0
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```100mm```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{100}mm"",
+ ""justification"": ""The input text contains a numerical value '100' followed by a scale unit 'mm'. The numerical value '100' is enclosed within curly braces as it matches the parameter description of a numerical value with possible scale units.""
+}
+```"
+2024-11-18-17-09-10-458-772181eb334043d8ac98,"TrialID: 0
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```EUR```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""EUR"",
+ ""justification"": ""The provided input text is 'EUR', which is already in the correct ISO-4217 format and matches one of the valid choices directly.""
+}
+```"
+2024-11-18-17-09-11-795-78e3a30ee305fa0d314f,"TrialID: 0
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Notional: 10m
+Client pays: 6M Term SOFR, semi-annual, act/360
+Client receives: 3.45%, semi-annual, 30/360
+Start date: 10 November 2009
+Tenor: 5y
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10m
+Client pays: 6M Term SOFR, semi-annual, act/360
+Client receives: 3.45%, semi-annual, 30/360
+Start date: 10 November 2009
+Tenor: 5y
+```"
+2024-11-18-17-09-14-544-74a0b4e86e3f088b3dc0,"TrialID: 0
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```semi-annual```
+Parameter description: ```Payment frequency in months, for example 3 for quarterly.```
+Semicolon-delimited list of valid choices: ```['1', '3', '6', '12']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""6"",
+ ""justification"": ""The term 'semi-annual' refers to something occurring twice a year, which corresponds to a 6-month period. Thus, it maps to the parameter choice '6'.""
+}
+```"
+2024-11-18-17-09-16-105-7393872e69db4c649076,"TrialID: 0
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+USDEUR cross currency swap (fixed/fixed), 10 y maturity
+Client pays 2.3% USD, we pay 1.7% EUR
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%EUR cross currency swap (fixed/fixed), 10 y maturity
+Client pays 2.3% USD, we pay 1.7% EUR
+```"
+2024-11-18-17-09-24-569-7c538f18f0d7dfceafb6,"TrialID: 0
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+EURUSD cross currency swap (fix fix) with 5y tenor where client pays EUR 6% coupon, receives USD 7.5%
+Both legs are semiannual and 30/360
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%5y tenor where client pays EUR 6% coupon, receives USD 7.5%
+Both legs are semiannual and 30/360"
+2024-11-18-17-09-27-262-7f90aee4c3b6211c83ed,"TrialID: 0
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```semiannual```
+Parameter description: ```Payment frequency in months, for example 3 for quarterly.```
+Semicolon-delimited list of valid choices: ```['1', '3', '6', '12']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""6"",
+ ""justification"": ""The term 'semiannual' refers to an event occurring twice a year or every six months. This maps directly to the parameter value '6' in the list of valid choices, representing a payment frequency in months.""
+}
+```"
+2024-11-18-17-09-28-523-7c12871d3efa7cede9ef,"TrialID: 0
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+I have trade details
+Profile: USD Interest rate swap
+Tenor: 10 years, both legs quarterly
+We pay USD fixed 3.35%, client pays SOFR
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10 years, both legs quarterly
+We pay USD fixed 3.35%, client pays SOFR
+```"
+2024-11-18-17-09-29-952-7391b239fb93b1cdb5bd,"TrialID: 0
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell SOFR swap at three point five percent, maturity November 18, 2027
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%SOFR swap at three point five percent, maturity November 18, 2027"
+2024-11-18-17-09-31-301-7451ae9d422f76ab3ee2,"TrialID: 0
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+SOFR swap, we receive fixed, 10y tenor starting on Nov 19, 2024
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%SOFR swap, we receive fixed, 10y tenor starting on Nov 19, 2024
+```
+
+In this entry:
+- ""SOFR"" is tagged as the pay leg floating index because the Bank is engaging in a SOFR swap.
+- ""fixed"" is where the bank receives interest, which makes it the receive leg fixed rate.
+- ""10y"" is tagged as the tenor in years, indicating a 10-year duration.
+- ""Nov 19, 2024"" is tagged as the effective date of the trade."
+2024-11-18-17-09-36-456-71c197b7f4f32b7e14ce,"TrialID: 0
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Vanilla swap at 2.90%, we pay fixed, 10y maturity
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%2.90%, we pay fixed, 10y maturity
+```"
+2024-11-18-17-09-39-849-7a41983973a4a730bf67,"TrialID: 0
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+We receive 3.5 on 10-year swap, will pay SOFR plus twenty basis points, effective November 18, 2024
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%3.5 on 10-year swap, will pay SOFR plus twenty basis points, effective November 18, 2024"
+2024-11-18-17-09-41-524-7942aede9e360f7fe83c,"TrialID: 1
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell 10y SOFR swap at 3.45%
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10y SOFR swap at 3.45%
+2024-11-18-17-09-42-577-73e091c7794025e983c8,"TrialID: 1
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Executed trade receiving 4.50% fixed vs 1-month SOFR on $100mm notional, 2-year tenor, starting December 20th, 2023
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%4.50% fixed vs 1-month SOFR on 100mm notional, 2-year tenor, starting December 20th, 2023"
+2024-11-18-17-09-44-917-7af3b20bab99db0bfefe,"TrialID: 1
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```USD100mm```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""```{USD}100mm```"",
+ ""justification"": ""The parameter description mentions currency symbols, natural language descriptions, or ISO-4217 codes for currency. The input text 'USD100mm' contains 'USD', which is the ISO-4217 code for the United States Dollar.""
+}
+```"
+2024-11-18-17-09-46-011-75d09cb02e601686cc85,"TrialID: 1
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```USD100mm```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""USD{100mm}"",
+ ""justification"": ""The input text 'USD100mm' contains a numerical value '100' followed by the scale unit 'mm', representing 'millions'. The currency symbol 'USD' is not part of the amount to be highlighted, so only '100mm' is surrounded by curly braces.""
+}
+```"
+2024-11-18-17-09-47-681-7b5091b9dfc23137b7e1,"TrialID: 1
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Paying USD, receiving JPY, 2-year tenor, plus 32bps spread, ¥5bn notional
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%`.
+- The client is receiving JPY, so JPY is the ``.
+- The tenor is given as 2 years, which corresponds to `2y`.
+- ""Plus 32bps spread"" indicates `32`.
+- The notional amount is ¥5bn, which corresponds to `5bn` because it aligns with the receiving leg description.
+
+Now let's place these annotations into the original text:
+
+```
+Paying USD, receiving JPY, 2-year tenor, plus 32bps spread, ¥5bn notional
+```
+
+This maintains the original order and phrasing of the trade entry, with annotations added for identified parameters."
+2024-11-18-17-09-51-691-7c828d4ab35204d021d7,"TrialID: 1
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```0```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""N"",
+ ""param_value"": """",
+ ""justification"": ""The input text '0' does not correspond to any valid ISO-4217 currency code, nor does it map to any of the provided valid choices, which are currency codes. Therefore, a match could not be determined.""
+}
+```"
+2024-11-18-17-09-53-269-7a32826df66722b125cf,"TrialID: 1
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```0```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text '0' does not contain a currency symbol, natural language description, or ISO-4217 code. It is a numerical value without any relation to the specified parameter type.""
+}
+```"
+2024-11-18-17-09-54-214-72d29b25b9bece7e1f60,"TrialID: 1
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```0```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{0}"",
+ ""justification"": ""The input text contains the numerical value '0', which is a valid numerical amount according to the parameter description. There are no scale units or currency symbols present that need exclusion.""
+}
+```"
+2024-11-18-17-09-55-730-7750b16689cb8dd55007,"TrialID: 1
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Executed 2-year basis swap
+Paying EUR, receiving USD plus 85 basis points
+100mm notional
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%2-year basis swap
+Paying EUR, receiving USD plus 85 basis points
+100mm notional
+```"
+2024-11-18-17-09-57-352-7013b95007e7d99af185,"TrialID: 1
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```100mm```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text '100mm' does not contain any information related to a currency symbol, natural language description, or ISO-4217 code. Therefore, no annotations were made.""
+}
+```"
+2024-11-18-17-09-58-932-712289caecd69c9f55c5,"TrialID: 1
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```100mm```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{100mm}"",
+ ""justification"": ""The input text '100mm' contains a numerical value '100' and a scale unit 'mm'. Both the digits and the scale unit together represent the amount, so they are correctly enclosed within curly braces.""
+}
+```"
+2024-11-18-17-10-00-438-7ef0b4a20e16c45c6f9b,"TrialID: 1
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```EUR```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""EUR"",
+ ""justification"": ""The input text 'EUR' matches exactly one of the provided choices for the currency code in ISO-4217 format.""
+}
+```"
+2024-11-18-17-10-02-097-7770bb48b454a45d9e80,"TrialID: 1
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```USD```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""USD"",
+ ""justification"": ""The input text 'USD' exactly matches one of the provided valid choices, which is a currency code in strict ISO-4217 format.""
+}
+```"
+2024-11-18-17-10-03-908-7e6284bee1fa719bf567,"TrialID: 1
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Notional: 10m
+Client pays: 6M Term SOFR, semi-annual, act/360
+Client receives: 3.45%, semi-annual, 30/360
+Start date: 10 November 2009
+Tenor: 5y
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%Notional: 10m
+Client pays: 6M Term SOFR, semi-annual, act/360
+Client receives: 3.45%, semi-annual, 30/360
+Start date: 10 November 2009
+Tenor: 5y
+```"
+2024-11-18-17-10-06-149-777285356638dffb7fee,"TrialID: 1
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```semi-annual```
+Parameter description: ```Payment frequency in months, for example 3 for quarterly.```
+Semicolon-delimited list of valid choices: ```['1', '3', '6', '12']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""6"",
+ ""justification"": ""The input text 'semi-annual' refers to a payment frequency that occurs twice a year, which correlates to every 6 months. Hence, '6' is the appropriate choice from the provided list of valid choices.""
+}
+```"
+2024-11-18-17-10-07-822-795082ee02fa13e2c00f,"TrialID: 1
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```Notional: 10m```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text does not contain any information about the parameter related to currency symbol, natural language description, or ISO-4217 code. The text only contains information about the notional amount, '10m', but no mention of a currency.""
+}
+```"
+2024-11-18-17-10-10-945-7960b343f1d3cd3cc292,"TrialID: 1
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```Notional: 10m```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""Notional: {10m}"",
+ ""justification"": ""The input includes '10m', which matches the criteria for the parameter: a numerical value with a scale unit but without any currency symbols. Based on the description, we correctly identified and surrounded the amount and its scale unit with curly braces.""
+}
+```"
+2024-11-18-17-10-12-795-77b1b9b2a653b74d937b,"TrialID: 1
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+USDEUR cross currency swap (fixed/fixed), 10 y maturity
+Client pays 2.3% USD, we pay 1.7% EUR
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%USDEUR cross currency swap (fixed/fixed), 10 y maturity
+Client pays 2.3% USD, we pay 1.7% EUR
+```"
+2024-11-18-17-10-16-645-7a5094490be7791cca52,"TrialID: 1
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+EURUSD cross currency swap (fix fix) with 5y tenor where client pays EUR 6% coupon, receives USD 7.5%
+Both legs are semiannual and 30/360
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%5y tenor where client pays EUR 6% coupon, receives USD 7.5%
+Both legs are semiannual and 30/360"
+2024-11-18-17-10-19-027-7de3ac81d21f339fab0f,"TrialID: 1
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```semiannual```
+Parameter description: ```Payment frequency in months, for example 3 for quarterly.```
+Semicolon-delimited list of valid choices: ```['1', '3', '6', '12']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""6"",
+ ""justification"": ""The input text 'semiannual' refers to a payment frequency of twice a year, which corresponds to every 6 months. Therefore, it maps to the valid choice '6'.""
+}
+```"
+2024-11-18-17-10-20-799-71508c19c651bccbd645,"TrialID: 1
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+I have trade details
+Profile: USD Interest rate swap
+Tenor: 10 years, both legs quarterly
+We pay USD fixed 3.35%, client pays SOFR
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10 years, both legs quarterly
+We pay USD fixed 3.35%, client pays SOFR"
+2024-11-18-17-10-23-112-7043a454bf9bc759f9db,"TrialID: 1
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell SOFR swap at three point five percent, maturity November 18, 2027
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%SOFR swap at three point five percent, maturity November 18, 2027"
+2024-11-18-17-10-24-705-72f0a9be394359d61e10,"TrialID: 1
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+SOFR swap, we receive fixed, 10y tenor starting on Nov 19, 2024
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%fixed, 10y tenor starting on Nov 19, 2024
+```"
+2024-11-18-17-10-26-277-71f3b2fc79dc5772b684,"TrialID: 1
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Vanilla swap at 2.90%, we pay fixed, 10y maturity
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%2.90%, we pay fixed, 10y maturity"
+2024-11-18-17-10-40-801-7a539aad43a7b71dac8c,"TrialID: 1
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+We receive 3.5 on 10-year swap, will pay SOFR plus twenty basis points, effective November 18, 2024
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%3.5 on 10-year swap, will pay SOFR plus twenty basis points, effective November 18, 2024
+```"
+2024-11-18-17-10-43-052-76d38827c9810bbeb355,"TrialID: 2
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell 10y SOFR swap at 3.45%
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10y SOFR swap at 3.45%
+2024-11-18-17-10-44-259-72138bbd09b83c79ce3a,"TrialID: 2
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Executed trade receiving 4.50% fixed vs 1-month SOFR on $100mm notional, 2-year tenor, starting December 20th, 2023
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%4.50% fixed vs 1-month SOFR on 100mm notional, 2-year tenor, starting December 20th, 2023"
+2024-11-18-17-10-45-783-78b38f7116ba8ab01d9b,"TrialID: 2
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```USD100mm```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""```{USD}100mm```"",
+ ""justification"": ""The parameter description specifies looking for currency symbols, natural language descriptions, or ISO-4217 codes related to currency. In the input text, 'USD' is the ISO-4217 code for the United States Dollar, which matches the parameter description requirements.""
+}
+```"
+2024-11-18-17-10-46-976-72209b6374ed952f1db5,"TrialID: 2
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```USD100mm```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""USD{100mm}"",
+ ""justification"": ""The input text contains the numerical value '100' followed by the scale unit 'mm', which stands for millions. The parameter description specifies to include only the digits and scale units, excluding any currency symbols like 'USD'. Hence, '100mm' is correctly annotated.""
+}
+```"
+2024-11-18-17-10-49-364-7e938ed1a69d8e8fe2ca,"TrialID: 2
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Paying USD, receiving JPY, 2-year tenor, plus 32bps spread, ¥5bn notional
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%USD, receiving JPY, 2-year tenor, plus 32bps spread, ¥5bn notional"
+2024-11-18-17-10-51-272-7ef1869fc49f909010a3,"TrialID: 2
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```5bn```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{5}bn"",
+ ""justification"": ""The input text '5bn' contains a numeric value '5' that could be interpreted as currency, though it lacks a specific currency symbol, ISO code, or explicit natural language description. Here, '5' can signify a currency amount, though not explicitly identifying any currency.""
+}
+```"
+2024-11-18-17-10-52-723-7a50a5a629575be95302,"TrialID: 2
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```5bn```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{5bn}"",
+ ""justification"": ""The input text '5bn' includes a numerical value '5' and a scale unit 'bn' which represents 'billions'. This matches the parameter description, which specifies identifying numerical amounts with their scale units but without any currency symbols.""
+}
+```"
+2024-11-18-17-10-55-143-79d09146a3a3f61704a4,"TrialID: 2
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```USD```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""USD"",
+ ""justification"": ""The input text is 'USD', which is exactly one of the provided valid choices and matches the ISO-4217 format.""
+}
+```"
+2024-11-18-17-10-56-020-70d28a3b5c2384fda9a9,"TrialID: 2
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```JPY```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""JPY"",
+ ""justification"": ""The input text 'JPY' matches exactly one of the valid choices in the provided ISO-4217 currency code format.""
+}
+```"
+2024-11-18-17-10-57-198-78c2a4100e49e9d63b1b,"TrialID: 2
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Executed 2-year basis swap
+Paying EUR, receiving USD plus 85 basis points
+100mm notional
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%2-year basis swap Paying EUR, receiving USD plus 85 basis points 100mm notional"
+2024-11-18-17-10-59-412-70f3a3e4e9ee5aad7aa6,"TrialID: 2
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```100mm```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text '100mm' does not contain any information about a currency symbol, natural language description, or ISO-4217 code. It lacks any indication of a currency like the examples provided ($, dollar, USD).""
+}
+```"
+2024-11-18-17-11-00-750-75008daf26e44a4010e8,"TrialID: 2
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```100mm```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{100mm}"",
+ ""justification"": ""The input '100mm' contains the numerical value '100' followed by the scale unit 'mm'. According to the parameter description, the numerical value and its associated scale unit should be enclosed in curly braces. '100' is a numerical value and 'mm' is treated as a scale unit in this context.""
+}
+```"
+2024-11-18-17-11-02-724-7af3b5c6cb711ee679ce,"TrialID: 2
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```EUR```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""EUR"",
+ ""justification"": ""The input text 'EUR' is a currency code in strict ISO-4217 format, consisting of three uppercase letters. It directly matches one of the provided valid choices, which is 'EUR'.""
+}
+```"
+2024-11-18-17-11-04-227-798188be11a353e7379f,"TrialID: 2
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Notional: 10m
+Client pays: 6M Term SOFR, semi-annual, act/360
+Client receives: 3.45%, semi-annual, 30/360
+Start date: 10 November 2009
+Tenor: 5y
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10m
+Client pays: 6M Term SOFR, 6-monthly, act/360
+Client receives: 3.45%, 6-monthly, 30/360
+Start date: 10 November 2009
+Tenor: 5y
+```"
+2024-11-18-17-11-06-603-7ca2a5642ce70e3cff7a,"TrialID: 2
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ``````
+Parameter description: ```Payment frequency in months, for example 3 for quarterly.```
+Semicolon-delimited list of valid choices: ```['1', '3', '6', '12']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""N"",
+ ""param_value"": """",
+ ""justification"": ""The input text is empty, so it is not possible to extract any parameter value related to the payment frequency.""
+}
+```"
+2024-11-18-17-11-07-658-79e181ac67a138a62f1f,"TrialID: 2
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```10m```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text '10m' does not contain any currency symbol, natural language description, or ISO-4217 code. Thus, there is no information to surround with curly braces.""
+}
+```"
+2024-11-18-17-11-09-011-76c18affca042401be7f,"TrialID: 2
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```10m```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{10m}"",
+ ""justification"": ""The input text '10m' provides a numerical value with a scale unit 'm', which fits the description of a numerical value including a scale unit, such as 'm' for millions. The numerical value along with its scale unit can be enclosed in curly braces as per the parameter description guidelines.""
+}
+```"
+2024-11-18-17-11-10-766-70109d6302b4d91c2341,"TrialID: 2
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```s```
+Parameter description: ```Payment frequency in months, for example 3 for quarterly.```
+Semicolon-delimited list of valid choices: ```['1', '3', '6', '12']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""N"",
+ ""param_value"": """",
+ ""justification"": ""The input text 's' does not provide any clear information about the payment frequency in months. Therefore, it cannot be mapped to any of the valid choices: '1', '3', '6', '12'.""
+}
+```"
+2024-11-18-17-11-12-504-7770b782f196d51b23a8,"TrialID: 2
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```0```
+Parameter description: ```Payment frequency in months, for example 3 for quarterly.```
+Semicolon-delimited list of valid choices: ```['1', '3', '6', '12']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""N"",
+ ""param_value"": """",
+ ""justification"": ""The input text '0' does not map to any of the valid choices for payment frequency, which are '1', '3', '6', or '12'. Zero months is not an acceptable or meaningful payment frequency.""
+}
+```"
+2024-11-18-17-11-13-991-77538a2cd46beac618f1,"TrialID: 2
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+USDEUR cross currency swap (fixed/fixed), 10 y maturity
+Client pays 2.3% USD, we pay 1.7% EUR
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10 y maturity
+Client pays 2.3% USD, we pay 1.7% EUR"
+2024-11-18-17-11-16-704-72c1a9fc88e63e4a6164,"TrialID: 2
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+EURUSD cross currency swap (fix fix) with 5y tenor where client pays EUR 6% coupon, receives USD 7.5%
+Both legs are semiannual and 30/360
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%5y tenor where client pays EUR 6% coupon, receives USD 7.5%
+Both legs are semiannual and 30/360"
+2024-11-18-17-11-18-488-73539d023d51d949685d,"TrialID: 2
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```semiannual```
+Parameter description: ```Payment frequency in months, for example 3 for quarterly.```
+Semicolon-delimited list of valid choices: ```['1', '3', '6', '12']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""6"",
+ ""justification"": ""The input text 'semiannual' refers to a payment frequency of twice a year, which corresponds to every 6 months. Therefore, it maps to the valid choice '6'.""
+}
+```"
+2024-11-18-17-11-19-901-7803a7b2b2a7035b592a,"TrialID: 2
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+I have trade details
+Profile: USD Interest rate swap
+Tenor: 10 years, both legs quarterly
+We pay USD fixed 3.35%, client pays SOFR
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10 years, both legs quarterly
+We pay USD fixed 3.35%, client pays SOFR
+```"
+2024-11-18-17-11-21-487-7451b89ee69b9f7652ea,"TrialID: 2
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell SOFR swap at three point five percent, maturity November 18, 2027
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%SOFR swap at three point five percent, maturity November 18, 2027
+```"
+2024-11-18-17-11-23-450-7e119cbd37d61f65ac6b,"TrialID: 2
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+SOFR swap, we receive fixed, 10y tenor starting on Nov 19, 2024
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%fixed, 10y tenor starting on Nov 19, 2024
+```"
+2024-11-18-17-11-25-524-7eb3846f13a9126fc28d,"TrialID: 2
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Vanilla swap at 2.90%, we pay fixed, 10y maturity
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%2.90%, we pay fixed, 10y maturity"
+2024-11-18-17-11-26-660-71c08a8bc775aef92ded,"TrialID: 2
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+We receive 3.5 on 10-year swap, will pay SOFR plus twenty basis points, effective November 18, 2024
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%3.5 on 10-year swap, will pay SOFR plus twenty basis points, effective November 18, 2024
+```"
+2024-11-18-17-11-29-140-7ce38c0f12e5699b2b31,"TrialID: 3
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell 10y SOFR swap at 3.45%
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10y SOFR swap at 3.45%
+2024-11-18-17-11-30-378-76d3bfbd86a06debac9e,"TrialID: 3
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Executed trade receiving 4.50% fixed vs 1-month SOFR on $100mm notional, 2-year tenor, starting December 20th, 2023
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%4.50% fixed vs 1-month SOFR on $100mm notional, 2-year tenor, starting December 20th, 2023"
+2024-11-18-17-11-32-393-72a388b783be697447eb,"TrialID: 3
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```100mm```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text '100mm' does not contain any currency symbol, natural language description, or ISO-4217 code as required by the parameter description. It only appears to be a measurement, not related to currency.""
+}
+```"
+2024-11-18-17-11-33-685-72b09a5d7fcf87d8ba96,"TrialID: 3
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```100mm```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{100mm}"",
+ ""justification"": ""The input text contains a numerical value '100' followed by a unit 'mm', which matches the parameter description as a numerical value with a scale unit. It does not include any currency symbols.""
+}
+```"
+2024-11-18-17-11-35-060-7a51a2eb6cdf37ed1342,"TrialID: 3
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Paying USD, receiving JPY, 2-year tenor, plus 32bps spread, ¥5bn notional
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%USD, receiving JPY, 2-year tenor, plus 32bps spread, ¥5bn notional
+```"
+2024-11-18-17-11-36-737-78a1bebe5d35404f7a29,"TrialID: 3
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```USD```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""USD"",
+ ""justification"": ""The input text 'USD' is a strict match to one of the provided valid ISO-4217 currency codes, specifically 'USD'.""
+}
+```"
+2024-11-18-17-11-38-092-70d382856e40682aa335,"TrialID: 3
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```5bn```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text '5bn' does not contain any currency symbol, natural language description, or ISO-4217 code for any currency. It appears to denote a quantity or abbreviation unrelated to currency.""
+}
+```"
+2024-11-18-17-11-39-258-70f39b13dfc4e76211bd,"TrialID: 3
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```5bn```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{5bn}"",
+ ""justification"": ""The text '5bn' represents a numerical amount with a scale unit 'bn' for billions, which matches the parameter description. There are no currency symbols or additional non-digit symbols included, thus correctly identifying it as a numerical value with a scale unit.""
+}
+```"
+2024-11-18-17-11-40-658-7d72babe6af63f701148,"TrialID: 3
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```JPY```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""JPY"",
+ ""justification"": ""The input text 'JPY' matches one of the valid choices 'JPY' exactly and adheres to the ISO-4217 format of three uppercase letters.""
+}
+```"
+2024-11-18-17-11-41-932-7882b2a88eea27c2b4ad,"TrialID: 3
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Executed 2-year basis swap
+Paying EUR, receiving USD plus 85 basis points
+100mm notional
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%2-year basis swap
+Paying EUR, receiving USD plus 85 basis points
+100mm notional"
+2024-11-18-17-11-45-540-74408f920f8523532620,"TrialID: 3
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```EUR```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""EUR"",
+ ""justification"": ""The input text 'EUR' is already in the strict ISO-4217 format of three uppercase letters, and it matches one of the provided valid choices 'EUR'.""
+}
+```"
+2024-11-18-17-11-47-070-76d091177ce677a750cc,"TrialID: 3
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Notional: 10m
+Client pays: 6M Term SOFR, semi-annual, act/360
+Client receives: 3.45%, semi-annual, 30/360
+Start date: 10 November 2009
+Tenor: 5y
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%Notional: 10m
+Client pays: 6M Term SOFR, semi-annual, act/360
+Client receives: 3.45%, semi-annual, 30/360
+Start date: 10 November 2009
+Tenor: 5y
+```"
+2024-11-18-17-11-49-175-72b384771a1d4c0b4a62,"TrialID: 3
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```semi-annual```
+Parameter description: ```Payment frequency in months, for example 3 for quarterly.```
+Semicolon-delimited list of valid choices: ```['1', '3', '6', '12']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""6"",
+ ""justification"": ""The input text 'semi-annual' refers to a payment frequency of twice a year, which commonly means every 6 months. This corresponds to the choice '6' in the provided list of valid choices.""
+}
+```"
+2024-11-18-17-11-50-892-7ba19d142dac64253f7a,"TrialID: 3
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```Notional: 10m```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text does not contain a currency symbol, natural language description, or ISO-4217 code. It only contains a numerical value for Notional, which is not related to the parameter description provided.""
+}
+```"
+2024-11-18-17-11-52-729-7c038b563d12b0da8282,"TrialID: 3
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```Notional: 10m```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""Notional: {10m}"",
+ ""justification"": ""The input text provides a numerical value '10m', which fits the parameter description as it includes digits and a scale unit ('m' for millions) without any currency symbols. Therefore, the complete information '10m' is surrounded by curly braces.""
+}
+```"
+2024-11-18-17-11-54-111-72d0a6e5fefb2b6fb2b4,"TrialID: 3
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+USDEUR cross currency swap (fixed/fixed), 10 y maturity
+Client pays 2.3% USD, we pay 1.7% EUR
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%USDEUR cross currency swap (fixed/fixed), 10 y maturity
+Client pays 2.3% USD, we pay 1.7% EUR
+```"
+2024-11-18-17-11-56-962-7e40aa03c48cf62b3372,"TrialID: 3
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+EURUSD cross currency swap (fix fix) with 5y tenor where client pays EUR 6% coupon, receives USD 7.5%
+Both legs are semiannual and 30/360
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%5y tenor where client pays EUR 6% coupon, receives USD 7.5%
+Both legs are 6-monthly and 30/360
+'''
+
+In the tagged trade entry, you'll notice that from the bank's perspective:
+- The tenor is tagged as `5y`.
+- The client pays EUR, so the bank receives EUR, making it the ``.
+- The client's pay rate (EUR) is tagged as ``.
+- The client receives USD, so the bank pays USD, making it the ``.
+- The client's receive rate (USD) is tagged as ``.
+- The frequency and basis of both legs are tagged using the `` and `` respectively."
+2024-11-18-17-12-02-341-7710b6796e0225366560,"TrialID: 3
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```0```
+Parameter description: ```Payment frequency in months, for example 3 for quarterly.```
+Semicolon-delimited list of valid choices: ```['1', '3', '6', '12']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""N"",
+ ""param_value"": """",
+ ""justification"": ""The input text '0' does not correspond to any of the valid choices ['1', '3', '6', '12'] for payment frequency. Zero months is not a valid frequency in this context as the acceptable values represent realistic time periods for payment intervals.""
+}
+```"
+2024-11-18-17-12-05-618-7c73bee1e57514bbae67,"TrialID: 3
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```0```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""N"",
+ ""param_value"": """",
+ ""justification"": ""The input text '0' does not correspond or map to any of the valid ISO-4217 currency codes provided: ['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']. It does not represent a currency code or its common symbol.""
+}
+```"
+2024-11-18-17-12-07-069-752288f29603655fa1ee,"TrialID: 3
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+I have trade details
+Profile: USD Interest rate swap
+Tenor: 10 years, both legs quarterly
+We pay USD fixed 3.35%, client pays SOFR
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10 years, both legs quarterly
+We pay USD fixed 3.35%, client pays SOFR
+```"
+2024-11-18-17-12-09-240-7f7186c3d8d1c289bec1,"TrialID: 3
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell SOFR swap at three point five percent, maturity November 18, 2027
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%three point five percent, maturity November 18, 2027"
+2024-11-18-17-12-12-716-7823b1e585c2f5e14039,"TrialID: 3
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+SOFR swap, we receive fixed, 10y tenor starting on Nov 19, 2024
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%SOFR swap, we receive fixed, 10y tenor starting on Nov 19, 2024
+```"
+2024-11-18-17-12-16-656-73a39a2ae5581939d3d8,"TrialID: 3
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Vanilla swap at 2.90%, we pay fixed, 10y maturity
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%2.90%, we pay fixed, 10y maturity"
+2024-11-18-17-12-19-888-77b29093cb363757bea4,"TrialID: 3
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+We receive 3.5 on 10-year swap, will pay SOFR plus twenty basis points, effective November 18, 2024
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%3.5 on 10-year swap, will pay SOFR plus twenty basis points, effective November 18, 2024
+```"
+2024-11-18-17-12-24-652-7b61a23caf0264e4e2ae,"TrialID: 4
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell 10y SOFR swap at 3.45%
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10y SOFR swap at 3.45%
+2024-11-18-17-12-26-944-7bd08d75032bafb122e4,"TrialID: 4
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Executed trade receiving 4.50% fixed vs 1-month SOFR on $100mm notional, 2-year tenor, starting December 20th, 2023
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%4.50% fixed vs 1-month SOFR on 100mm notional, 2-year tenor, starting December 20th, 2023"
+2024-11-18-17-12-31-399-743297966015fbb7720e,"TrialID: 4
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```USD100mm```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""```{USD}100mm```"",
+ ""justification"": ""The input text contains the ISO-4217 code 'USD', which matches the parameter description of a currency symbol or code.""
+}
+```"
+2024-11-18-17-12-33-104-7352bab4a8091ff76201,"TrialID: 4
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```USD100mm```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""USD{100mm}"",
+ ""justification"": ""The annotated part '100mm' matches the description as it contains the numerical value '100' followed by the scale unit 'mm' (representing 'millions'). 'USD' is not included as it is a currency symbol, which should be excluded based on the parameter description.""
+}
+```"
+2024-11-18-17-12-35-102-78e2b7aac9ef2e0ae71a,"TrialID: 4
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Paying USD, receiving JPY, 2-year tenor, plus 32bps spread, ¥5bn notional
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%USD, receiving JPY, 2-year tenor, plus 32bps spread, ¥5bn notional
+```
+
+In this trade, the bank is paying USD, meaning the client is receiving USD, and the bank is receiving JPY. The pay leg and receive leg have been identified accordingly."
+2024-11-18-17-12-37-386-756296f1a6c60d427206,"TrialID: 4
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```0```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""N"",
+ ""param_value"": """",
+ ""justification"": ""The input text '0' does not match or imply any ISO-4217 currency codes from the provided list of valid choices: ['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']. It is a numerical representation and there's no inherent or common mapping from '0' to any currency code based on the context provided or general financial notation.""
+}
+```"
+2024-11-18-17-12-38-983-7f62b069fedd78cd3950,"TrialID: 4
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```0```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text '0' does not contain any information related to a currency symbol, natural language description, or ISO-4217 code. The parameter specified is not present in the input.""
+}
+```"
+2024-11-18-17-12-40-452-7d42a25afd00a497cccd,"TrialID: 4
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```0```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{0}"",
+ ""justification"": ""The input text '0' is a numerical value that matches the parameter description of a numerical amount without additional symbols or text. While it does not have a scale unit or thousands separators, it fits the criteria of being a plain numeric value.""
+}
+```"
+2024-11-18-17-12-41-838-7d52a2b7f2771224f235,"TrialID: 4
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Executed 2-year basis swap
+Paying EUR, receiving USD plus 85 basis points
+100mm notional
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%2-year basis swap
+Paying EUR, receiving USD plus 85 basis points
+100mm notional
+```"
+2024-11-18-17-12-43-458-79f3a2f8d5fa07d78f18,"TrialID: 4
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```100mm```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text '100mm' does not contain any information about a currency symbol, natural language description, or ISO-4217 code.""
+}
+```"
+2024-11-18-17-12-44-939-7220941c4b23a5cf3afb,"TrialID: 4
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```100mm```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{100mm}"",
+ ""justification"": ""The input text '100mm' contains a numerical value '100' which is directly followed by a scale unit 'mm'. This matches the parameter description which specifies that the numerical value along with its scale unit should be identified and surrounded by curly braces.""
+}
+```"
+2024-11-18-17-12-46-365-70c0ba70f8eeb8c28ab6,"TrialID: 4
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```EUR```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""EUR"",
+ ""justification"": ""The input text 'EUR' directly matches one of the provided valid choices, which is 'EUR'. It adheres to the strict ISO-4217 format of three uppercase letters and is listed in the valid choices.""
+}
+```"
+2024-11-18-17-12-47-797-7f3191f8ed4ca0382e4b,"TrialID: 4
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```USD```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""USD"",
+ ""justification"": ""The input text 'USD' exactly matches one of the provided valid choices, which are strict ISO-4217 currency codes.""
+}
+```"
+2024-11-18-17-12-49-872-72139bb5adbdf65f1c27,"TrialID: 4
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Notional: 10m
+Client pays: 6M Term SOFR, semi-annual, act/360
+Client receives: 3.45%, semi-annual, 30/360
+Start date: 10 November 2009
+Tenor: 5y
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%Notional: 10m
+Client pays: 6M Term SOFR, semi-annual, act/360
+Client receives: 3.45%, semi-annual, 30/360
+Start date: 10 November 2009
+Tenor: 5y
+```"
+2024-11-18-17-12-52-544-75e182fc6e5e7fde6565,"TrialID: 4
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```semi-annual```
+Parameter description: ```Payment frequency in months, for example 3 for quarterly.```
+Semicolon-delimited list of valid choices: ```['1', '3', '6', '12']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""6"",
+ ""justification"": ""The term 'semi-annual' translates to a frequency of twice a year, or every 6 months, which matches the valid choice '6'.""
+}
+```"
+2024-11-18-17-12-54-153-7943b3498813942d0d00,"TrialID: 4
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```Notional: 10m```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text does not contain any information regarding a currency symbol, natural language description, or ISO-4217 code. It only contains a notional value but does not specify the currency.""
+}
+```"
+2024-11-18-17-12-56-673-73518eaaca41b49ae738,"TrialID: 4
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```Notional: 10m```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""Notional: {10m}"",
+ ""justification"": ""The input text 'Notional: 10m' contains '10m', which is a numerical value with a scale unit 'm' indicating millions. According to the parameter description, this fits the criteria of numerical value with a scale unit, and hence it is surrounded by curly braces.""
+}
+```"
+2024-11-18-17-12-58-359-77c3854870b85fd2b5e0,"TrialID: 4
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+USDEUR cross currency swap (fixed/fixed), 10 y maturity
+Client pays 2.3% USD, we pay 1.7% EUR
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%USDEUR cross currency swap (fixed/fixed), 10 y maturity
+Client pays 2.3% USD, we pay 1.7% EUR
+```"
+2024-11-18-17-13-00-112-7540902d2a85bfbea346,"TrialID: 4
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```USDEUR```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""N"",
+ ""param_value"": """",
+ ""justification"": ""The input text 'USDEUR' consists of two concatenated currency codes: 'USD' and 'EUR'. This does not match the requirement of a single, valid currency code in ISO-4217 format from the list of valid choices. Since the input does not clearly represent a single currency code, extraction of a valid parameter value is unsuccessful.""
+}
+```"
+2024-11-18-17-13-02-275-7941970001adc5ae56e9,"TrialID: 4
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+EURUSD cross currency swap (fix fix) with 5y tenor where client pays EUR 6% coupon, receives USD 7.5%
+Both legs are semiannual and 30/360
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%5y tenor where client pays EUR 6% coupon, receives USD 7.5%
+Both legs are semiannual and 30/360"
+2024-11-18-17-13-04-216-7793a754bf80f2579d5a,"TrialID: 4
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```semiannual```
+Parameter description: ```Payment frequency in months, for example 3 for quarterly.```
+Semicolon-delimited list of valid choices: ```['1', '3', '6', '12']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""6"",
+ ""justification"": ""The input text 'semiannual' indicates a payment frequency of twice a year, which corresponds to a 6-month interval. This matches the valid choice '6'.""
+}
+```"
+2024-11-18-17-13-06-640-74738f1acdf3b193945b,"TrialID: 4
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+I have trade details
+Profile: USD Interest rate swap
+Tenor: 10 years, both legs quarterly
+We pay USD fixed 3.35%, client pays SOFR
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%USD Interest rate swap
+Tenor: 10 years, both legs quarterly
+We pay USD fixed 3.35%, client pays SOFR
+'''
+
+Here's how the trade entry looks with the tagged parameters."
+2024-11-18-17-13-09-790-7c02a780299b695f7898,"TrialID: 4
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell SOFR swap at three point five percent, maturity November 18, 2027
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%SOFR swap at three point five percent, maturity November 18, 2027"
+2024-11-18-17-13-11-261-7b329298be87058c41e1,"TrialID: 4
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+SOFR swap, we receive fixed, 10y tenor starting on Nov 19, 2024
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%fixed, 10y tenor starting on Nov 19, 2024
+```"
+2024-11-18-17-13-13-443-7bf28ab66fc55531cd45,"TrialID: 4
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Vanilla swap at 2.90%, we pay fixed, 10y maturity
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%2.90%, we pay fixed, 10y maturity
+```"
+2024-11-18-17-13-17-036-7db1b803e212fb2a31c8,"TrialID: 4
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+We receive 3.5 on 10-year swap, will pay SOFR plus twenty basis points, effective November 18, 2024
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%3.5 on 10-year swap, will pay SOFR plus twenty basis points, effective November 18, 2024
+```"
+2024-11-18-17-13-20-932-71d0804d9c0ec8979ae4,"TrialID: 5
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell 10y SOFR swap at 3.45%
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10y SOFR swap at 3.45%
+2024-11-18-17-13-24-426-76a08aecf1ba7c459b6c,"TrialID: 5
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Executed trade receiving 4.50% fixed vs 1-month SOFR on $100mm notional, 2-year tenor, starting December 20th, 2023
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%4.50% fixed vs 1-month SOFR on $100mm notional, 2-year tenor, starting December 20th, 2023"
+2024-11-18-17-13-28-409-7dd0a69ae8a670b8d438,"TrialID: 5
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```USD100mm```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""```{USD}100mm```"",
+ ""justification"": ""The input text contains 'USD', which is the ISO-4217 code for the United States Dollar, matching the parameter description.""
+}
+```"
+2024-11-18-17-13-29-510-7c51b506b0abbc506e46,"TrialID: 5
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```USD100mm```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""USD{100mm}"",
+ ""justification"": ""The parameter description specifies to include only numerical values and scale units (e.g., 'm', 'mm') without currency symbols like 'USD'. Here, '100mm' is the numerical value combined with the scale unit 'mm', and without the 'USD' currency symbol, which fits the requirement for annotation.""
+}
+```"
+2024-11-18-17-13-31-414-724083296e911f9832d6,"TrialID: 5
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Paying USD, receiving JPY, 2-year tenor, plus 32bps spread, ¥5bn notional
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%USD, receiving JPY, 2-year tenor, plus 32bps spread, ¥5bn notional
+```"
+2024-11-18-17-13-33-716-71d081eab01754a7d1aa,"TrialID: 5
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```USD```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""USD"",
+ ""justification"": ""The input text 'USD' matches directly with one of the valid ISO-4217 currency codes provided in the list of choices.""
+}
+```"
+2024-11-18-17-13-34-968-7bf3aa0c4a1d0d08f9a2,"TrialID: 5
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```5bn```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text '5bn' does not contain any information that matches the description of a currency symbol, natural language description, or ISO-4217 code. Therefore, no pieces of information could be annotated.""
+}
+```"
+2024-11-18-17-13-36-321-7f23835cfac91f0c1b53,"TrialID: 5
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```5bn```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{5bn}"",
+ ""justification"": ""The input text '5bn' contains a numerical value '5' and a scale unit 'bn' which corresponds to 'billion'. Both are part of the described parameter and are surrounded by curly braces together.""
+}
+```"
+2024-11-18-17-13-37-408-79a192c503e867d127be,"TrialID: 5
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```JPY```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""JPY"",
+ ""justification"": ""The input text 'JPY' exactly matches one of the valid choices in the provided list, which represents the currency code for Japanese Yen following the ISO-4217 format.""
+}
+```"
+2024-11-18-17-13-38-762-7ed3b431a624a12ed443,"TrialID: 5
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Executed 2-year basis swap
+Paying EUR, receiving USD plus 85 basis points
+100mm notional
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%2-year basis swap
+Paying EUR, receiving USD plus 85 basis points
+100mm notional
+```"
+2024-11-18-17-13-41-571-7c029adba86fa73f448f,"TrialID: 5
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```100mm```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text '100mm' does not contain any information related to a currency symbol, natural language description, or ISO-4217 code. Therefore, no annotations with curly braces were made.""
+}
+```"
+2024-11-18-17-13-42-809-76c386d1bc85667ce2df,"TrialID: 5
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```100mm```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{100}mm"",
+ ""justification"": ""The input text includes a numerical value '100' followed by 'mm', which is identified as a unit of scale. These elements match the parameter description requirements, so '100mm' is correctly surrounded by curly braces.""
+}
+```"
+2024-11-18-17-13-44-278-70d1bdc7a22e2cbb11d0,"TrialID: 5
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```EUR```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""EUR"",
+ ""justification"": ""The input text 'EUR' perfectly matches one of the provided valid choices, 'EUR', which is a currency code in strict ISO-4217 format.""
+}
+```"
+2024-11-18-17-13-46-005-7ee3a4766ccfd092dea7,"TrialID: 5
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Notional: 10m
+Client pays: 6M Term SOFR, semi-annual, act/360
+Client receives: 3.45%, semi-annual, 30/360
+Start date: 10 November 2009
+Tenor: 5y
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10m
+Client pays: 6M Term SOFR, semi-annual, act/360
+Client receives: 3.45%, semi-annual, 30/360
+Start date: 10 November 2009
+Tenor: 5y
+```"
+2024-11-18-17-13-48-132-7de1922cce42b99704b4,"TrialID: 5
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```10m```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text '10m' does not contain any information that matches a currency symbol, natural language description, or ISO-4217 code. Therefore, no annotations with curly braces were added.""
+}
+```"
+2024-11-18-17-13-49-654-7bf28956b088a682cfd1,"TrialID: 5
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```10m```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{10m}"",
+ ""justification"": ""The input text '10m' contains a numerical value '10' followed by a scale unit 'm', which matches the parameter description of a numerical value including a scale unit. There are no currency symbols or additional text that need to be excluded from the annotation.""
+}
+```"
+2024-11-18-17-13-51-805-7400b7fafa8738863d97,"TrialID: 5
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+USDEUR cross currency swap (fixed/fixed), 10 y maturity
+Client pays 2.3% USD, we pay 1.7% EUR
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10 y maturity
+Client pays 2.3% USD, we pay 1.7% EUR"
+2024-11-18-17-13-53-938-7f42b32b733e16e70d44,"TrialID: 5
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+EURUSD cross currency swap (fix fix) with 5y tenor where client pays EUR 6% coupon, receives USD 7.5%
+Both legs are semiannual and 30/360
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%5y tenor where client pays EUR 6% coupon, receives USD 7.5%
+Both legs are semiannual and 30/360
+```"
+2024-11-18-17-13-56-816-74f1afbd03a780314034,"TrialID: 5
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```semiannual```
+Parameter description: ```Payment frequency in months, for example 3 for quarterly.```
+Semicolon-delimited list of valid choices: ```['1', '3', '6', '12']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""6"",
+ ""justification"": ""The input text 'semiannual' refers to twice a year, which corresponds to a payment frequency of every 6 months. This matches the valid choice '6'.""
+}
+```"
+2024-11-18-17-13-58-686-7d53964ff9a236c5d39c,"TrialID: 5
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+I have trade details
+Profile: USD Interest rate swap
+Tenor: 10 years, both legs quarterly
+We pay USD fixed 3.35%, client pays SOFR
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10 years, both legs quarterly
+We pay USD fixed 3.35%, client pays SOFR"
+2024-11-18-17-14-00-981-73428e7e8f37081107e4,"TrialID: 5
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell SOFR swap at three point five percent, maturity November 18, 2027
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%SOFR swap at three point five percent, maturity November 18, 2027
+```"
+2024-11-18-17-14-04-562-71b19f59b5f3ea7d12d3,"TrialID: 5
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+SOFR swap, we receive fixed, 10y tenor starting on Nov 19, 2024
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%fixed, 10y tenor starting on Nov 19, 2024"
+2024-11-18-17-14-08-286-7581a3f6810df366c69b,"TrialID: 5
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Vanilla swap at 2.90%, we pay fixed, 10y maturity
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%2.90%, we pay fixed, 10y maturity
+```"
+2024-11-18-17-14-11-684-7c119b2a0f79a44902f0,"TrialID: 5
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+We receive 3.5 on 10-year swap, will pay SOFR plus twenty basis points, effective November 18, 2024
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%3.5 on 10-year swap, will pay SOFR plus twenty basis points, effective November 18, 2024
+```"
+2024-11-18-17-14-16-733-76e3a2277658d0739d65,"TrialID: 6
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Sell 10y SOFR swap at 3.45%
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%10y SOFR swap at 3.45%
+2024-11-18-17-14-19-192-7e839c80f28c2dbe69df,"TrialID: 6
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Executed trade receiving 4.50% fixed vs 1-month SOFR on $100mm notional, 2-year tenor, starting December 20th, 2023
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%4.50% fixed vs 1-month SOFR on $100mm notional, 2-year tenor, starting December 20th, 2023"
+2024-11-18-17-14-23-451-7473a9b2a6432296fc4e,"TrialID: 6
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```USD100mm```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{USD}100mm"",
+ ""justification"": ""The input text contains 'USD', which matches the example of the ISO-4217 currency code provided in the parameter description.""
+}
+```"
+2024-11-18-17-14-24-708-7310b88e490f7f87c818,"TrialID: 6
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```USD100mm```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""USD{100mm}"",
+ ""justification"": ""The input text contains '100mm', which is the numerical value and the scale unit 'mm' (assumed to mean million or similar), excluding the currency symbol 'USD'. The requirement specifies that symbols like 'USD' should not be included in the annotation, only the digits and scale units.""
+}
+```"
+2024-11-18-17-14-26-331-77108d623a1869b0c7d8,"TrialID: 6
+You are a financial expert for interest rate swaps, and you understand trader messages well.
+You analyse the messages from the perspective of the Bank.
+You will be provided with a trade entry and a list with parameter descriptions.
+Every parameter description is a dictionary the parameter 'name' and 'description' keys.
+For every parameter in the list of parameter descriptions try to find this parameter in the trade entry.
+If you can not find the parameter then skip it.
+Otherwise tag the value of the parameter in the text. Do not worry about the format.
+
+parameters beginning 'pay' mean that the BANK is paying.
+parameters beginning 'rec' mean that the CLIENT is receiving.
+The trade text might be from the client's perspective, but you are smart enough to get the tags correct.
+
+Parameter descriptions:
+'''
+[
+ {
+ 'name': 'effective_date',
+ 'description': 'Effective date of the trade'
+ },
+ {
+ 'name': 'maturity_date',
+ 'description': 'Maturity date of the trade'
+ },
+ {
+ 'name': 'tenor_years',
+ 'description': 'Tenor in years, usually formatted like Xy, common values are 1,2,5,10.'
+ },
+ {
+ 'name': 'pay_leg_notional',
+ 'description': 'Pay leg notional amount, Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'pay_leg_ccy',
+ 'description': '
+ Pay leg payment currency in 3-letter ISO-4217 format, for example USD. Look for Currency Descriptions:
+The trade entry will typically specify the payment currencies for both the pay leg and the receive leg. These currencies are often indicated by 3-letter ISO codes like USD, EUR, GBP, etc.
+
+Common keywords/phrases to search for:
+
+'Pays [currency]'
+'Receives [currency]'
+'[currency] payment'
+'Currency: [currency]'
+'Pay leg currency'
+'Receive leg currency'
+
+Examples:
+
+'Paying EUR, receiving USD'
+'Bank pays USD, receives EUR'
+
+2. Contextual Information:
+Sometimes, the trade entry provides more contextual details such as fixed or floating rates or the index used for the payment. The pay leg currency often appears with details like the interest rate index (e.g., SOFR, LIBOR), while the receive leg currency could be linked to a fixed rate or percentage.
+
+Example:
+'Bank pays 6M Term SOFR, receiving 3.45%'
+
+3. Use of Keywords for Identifying Pay/Receive Legs:
+Typically, the pay leg is the one where the trade participant makes the payment, and the receive leg is where they are receiving the payment. In many cases:
+
+The pay leg currency will follow the keyword 'pays' or 'paying'.
+The receive leg currency will follow the keyword 'receives' or 'receiving'.
+Example:
+'Paying EUR, receiving USD' would indicate:
+Pay leg currency = EUR
+Receive leg currency = USD
+4. Search for Currency Pairs:
+If the trade involves a currency swap or cross-currency transaction, you may encounter currency pairs. For instance:
+
+'Paying EUR/USD, receiving GBP/USD'
+You would need to extract each currency individually from the pairs:
+
+Pay leg currency = EUR
+Receive leg currency = GBP
+
+5. Handle Missing or Implied Currencies:
+If the trade entry doesn’t explicitly mention the currencies, they might be implied by context or might need to be inferred from the financial instrument type (e.g., if it's a EUR/USD swap, then EUR is the pay leg and USD is the receive leg).
+
+Example Steps to Extract Currencies:
+Step 1: Look for the key phrases in the text:
+
+'Pays [currency]' and 'Receives [currency]'
+Step 2: Parse the values:
+If the text includes 'Paying EUR, receiving USD', then:
+Pay leg currency = EUR
+Receive leg currency = USD
+Step 3: Handle alternate descriptions or implied currencies:
+If only the notional value is specified (e.g., 'Pay 10 million'), try to infer the currency by context.
+For example, 'Bank pays 10 million' could imply a default currency like USD unless otherwise specified.
+
+ '
+ },
+ {
+ 'name': 'pay_leg_freq_months',
+ 'description': 'Pay leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'pay_leg_basis',
+ 'description': 'The day count basis specified in 'Pay', for example act/360. This is not the currency, do not get confused.'
+ },
+ {
+ 'name': 'pay_leg_float_index',
+ 'description': 'Pay leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'pay_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'pay_leg_fixed_rate_pct',
+ 'description': 'Pay leg fixed rate in percent, for example 3.45% (include the % sign in tag).'
+ },
+ {
+ 'name': 'rec_leg_notional',
+ 'description': 'Receive leg notional amount. Do not tag currency. It might use abbreviations like k, m, b. If Notional is given then use it as pay_leg_notional.'
+ },
+ {
+ 'name': 'rec_leg_ccy',
+ 'description': 'The currency specified for the receiver / seller. It might be a 3 letter ISO format or a symbol, or something else'
+ },
+ {
+ 'name': 'rec_leg_freq_months',
+ 'description': 'Receive leg payment frequency in months, for example 3.'
+ },
+ {
+ 'name': 'rec_leg_basis',
+ 'description': 'Receive leg day count basis as specified, for example act/360. Note this is not currency so the output shouldn't be in 3-letter ISO-4217 format.'
+ },
+ {
+ 'name': 'rec_leg_float_index',
+ 'description': 'Receive leg floating interest rate index as specified, e.g., 3m Term SOFR, or just SOFR. use the full term if given.'
+ },
+ {
+ 'name': 'rec_leg_float_spread_bp',
+ 'description': 'Receive leg spread in basis points, for example 30 (omit for a fixed leg, 0 or omit if not specified).'
+ },
+ {
+ 'name': 'rec_leg_fixed_rate_pct',
+ 'description': 'Receive leg fixed rate, for example 3.45%. Usually a expressed as a percent (include the % sign in tag) (omit for a floating leg).'
+ }
+]
+'''
+
+Trade entry:
+'''
+Paying USD, receiving JPY, 2-year tenor, plus 32bps spread, ¥5bn notional
+'''
+
+You must return the original trade entry text with the addition of xml like annotations.
+The annotations should use the filed names above.
+Not all fields will be present.
+
+For example:
+Sell 2y SOFR swap at 2.5%
+Becomes:
+Sell 2y SOFR swap at 2.5%
+
+You must not change the text between the tags.
+Do not reformat dates, fix typos or change any of the words in any way.
+
+Do not tag more than is needed, for example:
+Tenor: 5 years
+Becomes
+Tenor: 5 years
+
+Pay close attention to trade direction. We are always taking the role of the BANK.
+This means that if the Client Pays, We receive. For example:
+Client Pays 3% Client Receives 3.5%
+Becomes:
+Client Pays 3% Client Receives 3.5%USD, receiving JPY, 2-year tenor, plus 32bps spread, ¥5bn notional"
+2024-11-18-17-14-28-609-7253bfdb12da875d55b5,"TrialID: 6
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": """",
+ ""param_value"": """",
+ ""justification"": """"
+}
+Input text: ```USD```
+Parameter description: ```Currency code in strict ISO-4217 format of three uppercase letters, no variations allowed.```
+Semicolon-delimited list of valid choices: ```['CAD', 'EUR', 'GBP', 'HKD', 'JPY', 'USD']```
+
+Keep in mind that the input text does not need to be one of the valid choices. Rather, you must use your knowledge as
+Senior Quantitative Analyst to determine if the input has the same meaning or maps to one of the valid choices,
+without necessarily being exactly the same or having the same format.
+
+Examples:
+ - When input text is $, a valid choice may be USD
+ - When input text is %, a valid choice may be percent","```json
+{
+ ""success"": ""Y"",
+ ""param_value"": ""USD"",
+ ""justification"": ""The input text 'USD' is already in strict ISO-4217 format as described and is directly one of the provided valid choices.""
+}
+```"
+2024-11-18-17-14-29-688-7581bc3f41a776011ae2,"TrialID: 6
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```5bn```
+Parameter description: ```Currency symbol, natural language description or ISO-4217 code.
+Semicolon-delimited examples: $; dollar; USD
+```","```json
+{
+ ""success"": ""N"",
+ ""annotated_text"": """",
+ ""justification"": ""The input text '5bn' does not contain information that relates to a currency symbol, natural language description of a currency, or an ISO-4217 currency code.""
+}
+```"
+2024-11-18-17-14-30-809-70339510baf671c6e6dc,"TrialID: 6
+You will be provided with an input text and a description of a parameter.
+Your goal is to surround each piece of information about this parameter you find in the input text by curly braces.
+Use multiple non-nested pairs of opening and closing curly braces if you find more than one piece of information.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"":
+ ""annotated_text"": "",""
+ ""justification"": """"
+}
+Input text: ```5bn```
+Parameter description: ```Numerical value of the amount (including possible space, commas and other
+decimal point and thousands separators between digits) or its text representation (e.g. 'ten')
+including any scale unit such as 'm' or 'millions', 'b' or 'bn' or 'billions' but excluding any
+currency symbols such as '$', 'USD' or 'dollars'.
+
+Ensure you do not include anything other than digits and scale units, even if additional non-digit
+symbols such as a currency symbol are not separated by a space from the digits which may happen
+especially with the currency amount.
+
+Pay attention to the examples where you initially provided an incorrect answer:
+
+Input: $100m
+Your answer: {$100}m
+Correct answer: ${100m}
+
+Input: USD 100,000,000
+Your answer: USD {100},000,000
+Correct answer: USD {100,000,000}
+```","```json
+{
+ ""success"": ""Y"",
+ ""annotated_text"": ""{5bn}"",
+ ""justification"": ""The input text '5bn' contains a numerical value '5' followed by a scale unit 'bn', which falls under the definition of the parameter as a numerical amount with a scale unit. Hence, it is surrounded by curly braces.""
+}
+```"
+2024-11-18-17-14-32-162-7a419d38b01286554330,"TrialID: 6
+You will be provided with an input text, a description of a parameter, and possible values of this parameter.
+Your goal is to extract the value of the parameter from the provided input text.
+
+You must reply with JSON formatted strictly according to the JSON specification in which all values are strings.
+The JSON must have the following keys:
+
+{
+ ""success"": ""