VUS Assumptions - illyfrancis/scribble GitHub Wiki

Need these questions answered

  1. SEB Client Cash Account Number - derived from a UAF lookup
    • What is it?
    • What is the rule? Is it the L60 account number for A account?
  • Need to sort out transaction reference id and transaction type, along with source system
    • Confirm there are four types (verbatim)
      • aw_action_type_cde - I think it refers to ActionWorld hence corporate actions
      • tcs_tran_type - No idea, could it be sonic?
      • fx_tran_type - from FX Away
      • gfts_tran_typ - I think it should say gtps but just a guess
    • Where is a system for mutual funds?
  • If I assume, mutual funds transactions contain ids related to MF system, then the FX information that flows through in VUS2 and subsequent flows must also contain the same id, so that it can identify the same transaction
  • The corporate actions r/p should contain FX required indicator in the transaction itself so the MF system or the FX Away system's message shouldn't interfere
  • Lastly, if we assume, the other cash transactions (no MF, no CorpActions) contained sonic reference id, we expect the FX AWay message should contain the same sonic reference id
  • We assume the account number to be contained within the transaction (in RTCR), need to confirm if it'll always be for type A, B or C (Head account) and never L60.
  • Confirm we're not expected to map from L60 to Head account etc and all transactions will consistently contain header accounts

Re-list assumptions from BRD

  • Need to list them out, just in case BRD changes later
  • Also confirm that:
    • there are other "examples" of TP and how the accounts and txns are working through out with other systems some of which are outdated and contains contradicting examples (e.g. that URT 5 message is sent back to VUS from Informediary) but those documents are treated as supporting material and we are only taking the BRD as the source of truth. Therefore if there are any requirements that are not listed in BRD, those shall not be considered true requirement even if something contrary to the BRD is mentioned in these other documents.

Assumptions

Transaction Id

  • The transaction Ids are consistent in its type
  • That is, if the transaction Id is based on a particular system's reference Id (e.g. SONIC etc) the associated transaction Id must be specified with the same system's reference Id (e.g. SONIC)
  • ???? how to specify this ????

RTCR ?

  • The source of the transaction information is RTCR and RTCR only
  • Each transaction records sourced from RTCR must have (in addition to other transaction information)
    • unique RTCR Id
    • transaction Id (in addition to unique RTCR Id)
    • associated transaction Id
      • this is the other leg of transactions
    • related account number (full 11 digits)
  • The transaction Ids are consistent in its type
    • that is, if the transaction Id is based on a particular system's reference Id (e.g. SONIC etc) the associated transaction Id must be specified with the same system's reference Id (e.g. SONIC)

UAF?

  • Given an account number, UAF can determine if the account belongs to SEB client (should be extendable to accept client id???)
    • Need example???
      • A Account 101 -> Yes,
      • B Account 203 -> Yes,
      • Account 211 -> No,
      • etc
  • Given an account number, UAF can indicate the account types according to "cash-away" types (e.g. A, B or C)
  • Given an account number, UAF can provide related "cash-away" account number(s)
    • For example,
      • Given account number of type A, UAF is expected to return an account number for type B and/or account number for type C
      • Given account number of type B, UAF is expected to return an account number for type A
      • Given account number of type C, UAF is expected to return an account number for type A
  • Assumed that the preceding capabilities are provided as callable/executable functions (NOT just some database tables containing these information that has to be queried by VUS)
  • Assumed that the functions executes and performs according to NFR where NFR is to be defined later

FX Away

  • Each message sent from FX Away to VUS will contain associated transaction Id and account number
  • Relating to VUS 2 and VUS 3 flows, the assumption is FX Away system emits required information (e.g. FX required indicator etc) via message queue

MFPS

VUS Message Types

  • Need guidance on VUS message type
    • have distinct message types for each VUS1, 2, etc
    • or just one?

Posting of Provisional Cash Transaction

  • As of 1 Aug, the requirements are still under discussion from the business
  • The detail of the handling of provisional transaction may have an impact on the rest of the design

VUS 1 Flow

Questions
  1. SEB Client Cash Account Number - derived from a UAF lookup
    • What is it?
Assumptions
  • The transactions will contain Account number in the form of head account (not L60)
  • when the output message include account number, it will always be in head account form

VUS 2 Flow

Questions
  • A contractual/actual indicator exists...
    • why do this in VUS2? why not in VUS1?
Assumptions
  • The static database described in BRD is managed and maintained external to VUS
  • The static database can determine the "contractual/actual" indicator from an account number with transaction type (RVP or DVP)
  • The transaction information from RTCR contains (corporate actions receivable/payable cash transaction)
    • the same transaction id as the transactions caused VUS 1
    • FX required indicator
    • Withholding Agent indicator
  • R/P - Receivable/payable, it is the transaction created by action world for an income or reorg payment and the transactions will flow through to RTCR (confirmed by Barb R)

VUS 5 Prov Flow

Conversation with Barb on 29th July but this is no longer true...

Q: For URT 5 Prov section, it appears there's no description for what to do with the incoming message from SEB. Is this correct or has it been updated since the last distribution of the document?

A: no - no action is needed when a VUS 5 prov is received - we already paid the account - what i need to change here however is the comment at the end of the sentance - "and bbh can now settle..." - change to "and now bbh can consider the transaction complete"

Further conversations

1:49:33 PM J - Hi, still working through the BRD and for URT 5 Prov section, it appears there's no description for what to do with the incoming message from SEB. Is this correct or has it been updated since the last distribution of the document?
Jul 29, 20131:55:00 PM B - no - no action is needed when a VUS 5 prov is received - we already paid the account - what i need to change here however is the comment at the end of the sentance - "and bbh can now settle..." - change to "and now bbh can consider the transaction complete"
1:57:56 PM J - I see. Having that comment would be clearer and it would make sense to update it.
4:06:57 PM J - The BRD suggests, for the "provisional" R/P transaction on A account should create VUS 1. Does that mean for "provisional" transactions there will not be corresponding transactions from B or C accounts? I think the "provisional" concept wasn't specified in the previous version of BRD that I reviewed so I'm trying to establish if there are any difference to the normal cases (i.e. non-provisional) Also I'd imagine there will be a flag in the transaction record to indicate if the transaction is "provisional". Is that correct?
4:09:15 PM B - yes to the flag although corporate actions systems is still thinking it over - as for B/C yes there will be a transaction but it will come from the market when the market actually makes the payment. This payment to a B account will not flow to an A since we already paid the A - BBH needs to take no action with SEB when the market pays B
4:19:21 PM B - also - back to the prov pay - i was wrong - we do not post to A, even provisionally until SEB says to so the flow is
4:19:43 PM B - "somehow" actionworld will tell us to pay A provisionally
4:19:51 PM B - we send a ytr 4 prov to seb
4:20:02 PM B - they pay and send a ytr 5 prov to us
4:20:06 PM B - we pay A
4:20:37 PM B - "two days latter" when the market pays us we pay B and send nothing to seb
5:01:53 PM J - so contrary to your initial answer about VUS 5 PROV message handling in VUS (where you say there's no action required) it seems that there's some action required by VUS to "initiate" we pay A two days later? Or am I confusing something?
5:03:52 PM B - yes you are confusing it - the VUS 5 prov initiates the A payment on privisional (contractual) payment date - the payment from the market initiates the B payment on actual settlement date - in this scenario A and b do not initiate each other
5:13:03 PM J - Ok thank you. I'm still confused but I'm going to take your word for it and hope it'll clear up for me eventually. So basically on the receipt of VUS 5 PROV message from SEB, there's no action required by VUS process. Which is consistent with your previous answer.
5:15:13 PM B - no - you still have it backwards - look at the single sentance steps i sent starting with the "somehow"

From page 9

UI Requirements

  • Who are the users?
  • Level of ACL to manage?

Assume ?

  • Further analysis and detailed requirement will be provided in due course

Alert/Monitoring

  • From BRD,
    • Have an alert process to generate a warning if VUS 4 or VUS 4 PROV have been sent but VUS 5 or VUS 5 PROV have not been received
  • Who to alert?
  • When to alert? - what is the condition?
  • How? Is it an UI?
  • How to set up?

Message creation

  • Generally speaking I assume that when the transaction record is created for account B/C there will be corresponding transaction created for account A and both of those transactions will flow through to RTCR
  • And I expect that each transaction records will hold the transaction reference id of the corresponding account's transaction
    • For example, the transaction for Account B will hold the transaction reference id of the transaction for Account A
    • also the reverse is true, that is the transaction for Account A will hold the transaction reference id of the transaction for Account B
  • When both of the transactions (B/C and A) are known to VUS the inital VUS 1 message may be created

External dependencies

  • Availability of MQ resources

Assumptions on NFR (lowest priority)

  • Transaction volume
  • the number of SEB's clients, or the number accounts for SEB's business
  • For capacity estimates/planning etc
    • Redundancy
  • Latency and throughput requirements