Professional Documents
Culture Documents
NSL Custody Requirements Effort Estimation Sheet Final v0 1
NSL Custody Requirements Effort Estimation Sheet Final v0 1
Reference 1
Business Execution Step These requirements are intended for the nostro and securities mgmt at the NSL level, not individual custody clients)* Reflecting movements into account balances from client trade & instructions* Assume prop will be kept under NIP platform)* Custody client could hold cash in different currencies. Therefore, the cash accounts could be in different currencies. * The system should allow user to query the cash account balances by currencies and by client account level.* Support of mulitple account models - full omnibus, firm and custody omnibus, and client segregated. (If the client accounts are segregated, it allows user to keep the corresponding segregated account number for the client in the record by currency level.)
Position Balances
These requirements are intended for the nostro and securities mgmt at the NSL level, not individual custody clients)* Reflecting movements into account balances from client trade & instructions
Maintenance of cash and depot balances for safekeeping clients (both clients and proprietary accounts). (assume prop will be kept under NIP platform)* Support of mulitple account models - full omnibus, firm and custody omnibus, and client segregated. (If the clients accounts are segregated, it allows user to keep the corresponding segregated security account number for the client in the record by custodian/market.)* The system should allow user to query the security account balances.
Support the incoming custody instruction by SWIFT message from clients * Support Cash in/out instructions* Support Security in/out instructions* Trade settlement instruction from client (DVP trade settlement instructions from client)
Capture client custody trades:- FID- EQ- Treasury Trades* Reflecting movements into account balances from client trade & instructions
Settlement Instruction generation ???- Detailed rules to be analyzed(NO SI for custody client trades needed, ONLY the "DVP Trade settlement instruction" from client will be required)* Cash out intsructions* Security out intsructions(YES, these will trigger SWIFT instructions but user could have an option whether a SWIFT is triggered)* Generate the relevant instructions to agents.
processingFlexible to generate payment instruction as per clients standing instructions under special conditions (e.g. corporate events/ security trade/ forex), where these standing instructions could also be maintained in the systems by users.
For done away trades and custody instructions (e.g. cash in/out and security in/out movements), advices should be generated and sent to custody clients via * Email* Fax* Physical delivery (Mailing)Depending on clients preference and static setup.
Account Models
Support multiple account models (full omnibus, firm & custody omnibus & client seggregated)
Trade Types
10
Accrual Interest
11
Interest configuration setup for various clients* Client interest and charge calculation* Accrual interest calculation for cash accounts * Client interest & charge MTD accrual
Funding Projection
12
Support the consolidation of nostro and custodian cash balances to determine the funding projections/ requirements.* Monitoring of future cash projections by currency for client and Nomura entities. Corresponding cash projection report could also be generated. * (Currently, NSL is sending this information to Nomura entities, e.g. NIHK) * Cash Balances on VD basis by EOM* Position balances on VD basis by EOM* All transactions done and cash / position movements in the month. Short position Reports* Account Balances reports
Client statement
13
Reports
14
Outgoing feeds
15
Reconciliation Feeds- Nostro and Securities Reconciliation in TLM* Cash flow feeds to Smo cash sheet* MT535 / 950 statements to clients (IF POSSIBLE)* GL Posting
Collateral
16
Others
17
Swift Parsing Swift Rendering Maker Checker Scrren framework Business logic framework DB connectivity framework Posting of entitlements/dividends (which has to feed to Dodge)* posting to be reflected into the monthly statements* Posting of related charges/GST so as to reflect the changes into the cash accounts (these should feed to Dodge)
18
Other Requirements Priority How long can the back dated H transactions be done* Proprietary cash balances will not be maintained
* Cash balance query screens - Query account balances during the day- Query the balances by currency, by individual client * Cash balance update screens- Manual adjustment to cash account with back dated transactions
* Compute EOD cash balance by - Client accountCurrency* Processing for computing back dated transactions. * Logic to ensure back dated transactions are not beyond permissible limit
* Batch job to calculate EOD cash balances. Stock Balance * Position query / view screens - To see position transactions and the net position* Position adjustment screens- Manual adjustment to position account with back dated transactions Compute net position from custody transactions.* Processing for back dated corrections * Batch job to calculate EOD position balances.
Trade Settlement Instructions * Cash In/out Instructions* Security in/out Instructions * Incoming & outgoing swift messages * Instruction query screen* Display Incoming swift messages* Cash in instructions screen* Security in instructions screen* custody trade (DVP trade settlement instruction) screen* Trade settlemement status view * Swift message parsing* Trade processing on incoming trade * Cash balance update on cash in instruction* Position balance update on security in instruction* Processing on trade settlement instruction (DVP trade) update on both cash and security balances* Trigger Swift SI for the DVP trade * Process cash in instuctions* Process cash out instuctions * Swift interface- custody instruction FI Trade* EQ Trade * Treasury Trade Trade query screen * View Trades* Edit Trades* Add new Trade * Trade Capture* Process trades received (new, cancellation, amendments)* Update account cash balances* Update account position balances * Real time job / batch job to process incoming trades Trade Interface Which instructions are being referred to? (See REF #3)
N/A (Need validation only on whether the trades belong to custody clients, this should be done in
* SI (Covered earlier)* SI rules * Agent intsructions Same as SI - incoming* Transaction advice screen* Agent intruction screens * Complex SI generation logic based on various market rules. (7 rules approx)* Generation of agent instruction* Generation of transaction advices.* Swift message generation * SI generation process* Publishing to agent * Agent interface
Client standing instruction* Payment Is 4 eye principle / workflow required M Instruction for payment instruction processing * Screen for maintaining clinet standing intstruction Logic for generating payment instrcutions under various scenarios (~ 7 rules)* Generate payment instruction generation logic as per client standing instruction* Record payment instruction* Maker checker logic for payment instruction * Batch job to generate payment instruction Swift gateway for payment instructions Client preference & static data H * Screens to see confirms* Screen to submit confirms * Generate client confirm-Email- FaxPrint* Develop confirmation templates * Batch process to send confirms Thundehead Fax solutionsEmail
Account models Clarifications on requirements (See View client account static REF #1 and REF #2) Business logic implementaion for these account models
Clarifications & detailed BRD on various trade processing differences These trades are processed OUT from SMO/GLOSS platform, the custody solution are required to get these trades for monthly transaction reportong and capture the movements into the account balances.
Client interest static* Client charges Any specific indebtness reqirement * * Interest screens Asset based calculation * Compute client interest* Compute MTD accrual* Interest recalculation on manual adjustment * Daily interest calculation on EOD cash balance* Post monthly interest to client cash account* Interest re-calculation on manual adjustment * Batch job to compute client interest & accrual
H/ M
Can this be done by SMO Cash sheet? Msee REF# 15 (The Net cash flow needs to be sent to SMO Cash Sheet for Funding Movements. At least a report is needed to generate to feed to SMO Cash Sheet) H
Cash Balances on VD basis by EOM* Position balances on VD basis by EOM* All transactions done and cash / position movements in the month. Batch to generate EOM statements Short position Reports* Client account with short position (based on the tranasctions / movements)- daily report- on demand report* Account Balances reports on TD basis- daily report- on demand report* Account Balances reports on VD basis- daily report- on demand report Batch job to trigger reports
Logic for GL posting, client trades not fed Reconciliation (H)MT535/MT950 through SMO/ Gloss should be posted, (L)GL Posting (H)Cash Flow to SMO remaining should be blocked. * Post daily interst CASH Sheet (M) accrual to GL* Post monthly interest accrual to GL * Generate feed files for GL positing
Collateral requirement, where will this L be obtained from.Any other associated requirement
Functional Scope Generate Cash Balances by Currency Code & by Client Account ID
Query Screen should have the ability to: 1. Submit Queries on Account Balances - Intra Day / End of Day 2. Select Query Parameters by Currency, by Client ID, 3. Update Cash Balances to Client account based on Transactions processed in Core Custody system. These can be cash transactions or income transactions 4. to do Manual Adjustments to Cash Balances on system date and back dated transactions 5. to adjust back dated Cash Balances with restrictions such as: "Cannot Adjust for Matched Trades" or "Cannot adjust for Unauthorized Trades" Aggregation process 1. select accounts eligible for aggregation 2. select eligible position records per account by position currency for the same value date or settlement date, as defined by aggregation input criteria 3. aggregate eligible accounts by same currency code 4. aggregate by date type (value date & settlement date) 5. As of Date Reporting: where system date is greater than report date. 6. Back Dated transactions will be blocked where Trades are already in cleared state UI or Manual process: same as above
Query & Retrieval Process 1. Submit query inputs through UI 2. Query Parameters will be Currency code, Custodian ID, and market ID 3. Query Parameters will be pre-defined in the Query Database 4. Other parameters will include data ranges, report layout details, page break 5. Query submit will call the appropriate Database targets for the balances for Custodian and Market, defined by currency 6. Report Generation will be done as specified by Input parameters by the reports engine 7. Scheduler to configure and trigger EOD Position balances 8. Data Models & DB tables to support Account Hierarchy - for different nominee & beneficiary account types 9. Ability to make backdated adjustments with restrictions Available in HCL Solution - only for Stock Position Balances
Security Instruction Processing NOT Estimated as this is already supported by the HCL Solution
Trade Capture Facility - Manual Screen Apart from automatic updates based on instructions NOT yet cleared by Nomura, this is a manual facility to view & handle Trades already initiated, received, and cleared by NSL THIS IS AVAILABLE IN HCL SOLUTION
Module Requirements: 1. Module to capture Client Standing Instruction for Payments with associated SSI details 2. Generating Payment Instructions based on different scenario based rules. Rules will default on Client's SSI, Mode of Payment, Bank Identifier Codes to be used, Currency, Value Date of Payment, Payment gateway: RTGS, and others, Netting Instructions, Generate SWIFT MT types as required or through RTGS based on Client preferences 3. Modify the Business Logic or Instruction details
Client Static & Preferences will drive the processing path within the core custody solution of HCL. Whether for Instruction Management, Confirmations, Settlement Instructions (outbound) HCL solution will depend upona combination of Transaction Type, Client ID, Nominee Account Type, and specific client preferences to trigger a processing response
1. Confirmation Processing Module with following functionalities: a. Generate Client confirmations after making a verification call to the Client Static Data & Preferences file b. Submit Confirms to the Document Management System, with specific feed hand offs c. Or, submit Confirms to the other Confirmation delivery agents like Fax, Email channels for onward delivery d. Ability to define Confirmation Templates on an existing Content / Document Management System & maintain a repository of these templates with a unique template identification parameter. Templates can be customized to a client
The different Trade type supported by HCL solution include, buy, sell, short, cover & settlement types such as DVP, RVP, DF, and RF. There is an associated processing response triggered within the solution for each transaction type, and each Tran Type is mapped to a Posting code on the stock books and records (not currently supported within the solution) OR mapped to a client account
Accrual Engine to set up, define, apply, and calculate Interest Accrual at a client - account level, position level, based on beneficiary holding status of the cash positions only
Ref 1 will handle this requirement - no additional effort needed. Cash Balances positions will be reportable based on both Trade Date (deliverable / receivable) & also on Value Date (ledger cash but not available cash yet) upon cash settling in &out of account, the available cash will be updated. Cash Movements in the month can be generated as _ Opening Cash Balance for the Client Account + Net Cash Movements (inward / outward fully settled) + closing cash balances Short Positions will be represented by a negative Long Position Type in HCL Solution, Alternate treatment is to represent a Short Position simply with a "Short" Flag. The Security Positions Management Module in HCL Solution will flag a position as Short, when Tran Type SELL is Authorized without an underlying Deliverable Long position held by the Client within his Clearing Account held with Nomura. Where Nomura's client is not maintaining a segregated Nominee account with NSL, short position management will not be supported Position Keeping for Short transactions is fully supported in HCL Solution. Reports development will be an enhancement
MT 535 IS AVAILABLE SINCE SECURITY POSITION BALANCES ARE SUPPORTED MT 950 IS NOT AVAILABLE SINCE CASH POSITION BALANCES ARE NOT SUPPORTED IN HCL SOLUTION Logic for GL Posting: 1. a set of proprietary posting codes are available in the HCL Solution to support Posting of Trade Dated & Settle Dated transactions into a Stock GL 2. Cash Posting codes will need to be developed, as part of Ref 1 requirement 3. Recognizing a trade as SMO/Gloss can be supported by adding a Trade Capture field "Trade Source" = Gloss or SMO, to restrict HCL Solution from sending a GL posting feed for trades originating from these specified sources. Ref 2: Covers this requirement. However, a flag will be added to the Position Type: Clearing or Pledge, to distinguish between clear to deliver positions and positions not available for delivery due to an existing encumbrance or pledge on the position for the quantity of pledge. These pledge indicators will be reflected by HCL's Solution only where the input transaction type is "Collateral Out" & where a seperate account type = Collateral, & "Pledge" are created. These are Existing Functionality - No build required for Securities SWIFT messaging. However, SWIFT instruction processing for Cash in / Cash out will need to be built afresh - this has been estimated in Ref 1
Posting of Security Position Entitlements The posting instructions will be fed from an upstream system in the Security Position Management module in the HCL solution, which will then post the entitlements to the respect client - beneficiary accounts. It is expected that the feed would contain all necessary information in terms of: 1. Client - Account 2. Security ID or multiple Security ID's for different entitlement events falling due on the same posting date 3. Quantity to be added or reduced as per the Event Type that was processed in the upstream entitlements system 4. posting date 5. Event ID & Event Description against which the posting is being done 6. Nature of Event: Mandatory or Voluntary 7. Event Announcement Date, Record Date, Settle Date 8. Other details as are required to validate the feed Posting for Fee , Charges, & Levies: Another feed would come from Fee & Billing engine upstream with the instruction to post the charges, client-level fees, and levies/taxes to be charged back to target client account(s). It is expected that the upstream feed should contain the following information: 1. Posting Date 2. Nature of Charge: Fee, Levies, Taxes, and other detailed description of the charges 3. Amount of charge and related currency for the charge 4. Transaction ID for which the charge is applicable or a set of Transaction ID's against which the same charge type is applied 5. Rate of Charge & Basis of Chargeability - slab, flat, 6. Profile - level adjustments made for a client - if any 7. Net Amount of charge 8. Client Account ID against which the charge is made - it is likely that charges made to a client, are booked to a seperate "charges" account or multiple charges account, based on the Service level agreements executed by NSL with the client, into which different charges such as: Safekeeping charges, physical securities inventory charges, transaction - based charges, are posted. If different charge accounts are maintained, the upstream feed should provide the correct account
Module Requirements Report Module: 1. User submits input criteria to generate repors - date range, currency codes, client IDs specific or all 2. once submitted, the module fetches the Cash Balances from the Cash Positions Table, an internal logical file maintained within core system 3. The cash balances fetched are converted as per the display format specified 4. a UI is required to specify & map Databaase tables, field labels to the Reports layer Cash Position Management Module: 1. UI with ability to query, adjust, authorize cash balances of client accounts 2. Allow Back Dated Adjustment Transactions 3. Apply, Modify, Release restrictions on Back Dated Restrictions 4. Cash Positions Reporting 5. Ability to develop Cash Positions report EOD Cash Reporting Module: 1. Scheduler capability to set up EOD Cash Reports Generation and Rendering timelines, preconditions such as EOD, Date Roll over etc 2. same Back Dated Adjustment operations as in the above - 40 function points reusable 3. Generate alert for failed EOD jobs or predecessor jobs
90
80
Module: Stock Positions Management Module: Cash Positions Management - REF 1 (Enhancements to be made only for backdated adjustments of Cash Balances)
60
Instruction Management Module: 150 1. Create, View, Receive and upload Instructions 2. Validate Instructions 3. Notify parties for invalid instructions 4. update version numbers for valid instructions 5. lookup instruction routing mandates, in the client preferences database 6. send instructions to the mandated recipients for instructions to clear the trade 7. Support different Tran Types: DVP, RVP, DF, RF
Trade Capture Module 0 1. Create a New Trade 2. Enrich Trades with Nomura Entity ID, Client ID, Book ID (to indicate which Nomura Custody SEttlement Book the trade belongs to, Account Ownership: Own or Client Trade, Instrument ID, Instrument Short-Long Description, Trade Cash Values, Fees, levies, & charges, settlement location) 2. View Trades in "pending clearing " state 3. Edit for permitted fields 4. Manage Amends, Cancels) 5. submit trade for authorization 6. update client's clearing account balance with a block on deliverable / receivable quantity & cash as per Trade Operation: Buy /Sell 7. event capture facility to extract, upload, and aggregate all trades by client & account type (for same traded currency) 8. Interface to receive Trades & complete the processes as described in 1 to 7 above 9. A queue or temporary staging area to store the trades before they enter the Trade Capture Module will be done as part of Trade Enrichment & STP process descirbed above
HCL's solution supports this requirement -but as it is mentioned that detailed rules need to be analyzed, HCL is not submitting the effort estimation for this requirement. Can be developed on top of the base solution provided by HCL HCL Solution generates outbound settlement instructions on the following parameters: Tran Type = DVP (it also supports other delivery in/out instructions) Settlement Location is known (SSI derived from Traded Instrument) Take other market-specific rules such as:Settlement cut off, holidays & conventions, netted settlement rules, and others Settling Party is known (Trade for Trade SEttlement Insruction is generated) - HCL can work with Nomura to develop the detailed scenarios Agent Interface will be a seperate customization OR HCL can propose its own Securities Market Interface, a component seperate from the Core Custody Solution
150
120
Interest Accrual Module with ability to: 1. Define Accrual Conventions 2. Create Interest Types, Interest Rate & link to different asset classes 3. Define Account Types that qualify for Interest Accrual on Daily basis 4. Import eligible positions for calculation of Interest Accrual based on Asset Classes 5. Calculate Interest Accrual on Eligible positions. 6. Aggregate Accruals at position level into Client Account level 7. Post the Interest Accrual to Client Account at periodic intervals (Daily / Monthly) 8. for Overdraft Accounts, apply the appropriate Overdraft Interest by lookup at the Client level agreement, and follow the proceses at 6 to 7 9. Interest Accrual on Fixed Income SEcurities and eligible positions will NOT be covered under this functionality 10. Scheduled Interest Accrual Calculation and Posting to Client Account.
105
20
45
50
50
120
1140
complexity factors Account Cateogory: Cash Account Currency Code Date Range Parameter Client Identification Number Client Account Number List of values to look up and select the Input Criteria across the variables mentioned above
ILF Y
EIF N
Complexity Rating H
Account Categories: Cash & Securities Account Types: Nominee Omnibus, Nominee Segregated, Beneficiary Direct Account Ownership: Nomura Entity or Client Entity, Currency Code
Account Categories: Cash & Securities Account Types: Nominee Omnibus, Nominee Segregated, Beneficiary Direct Account Ownership: Nomura Entity or Client Entity, Currency Code
Account Categories: Cash & Securities Account Types: Nominee Omnibus, Nominee Segregated, Beneficiary Direct Account Ownership: Nomura Entity or Client Entity, Currency Code
Account Categories: Cash & Securities Account Types: Nominee Omnibus, Nominee Segregated, Beneficiary Direct Account Ownership: Nomura Entity or Client Entity, Currency Code, Transaction Types, SWIFT Message Types & Tag Values, Client Mandates for Settlement instructions, SSI's pre-defined for the client
Client Confirmation Mandates can be varied, based on the agreements a client has executed with his counterparty, executing broker, investment manager.
Interest Rate Types, Cash Account Types, Position Eligibility criteria, Y Posting Rules, frequency of calculation, calculation conventions used, and others
Multiple Parameters
Multiple Parameters
Requirements Description
Requirement Reference
cash Balances Position Balances Settlement Instruction - Incoming Custody Trade Capture Trade validation / Enrichment Settlement Instruction - Outgoing Payment Instruction - Outgoing Trade Processing - Confirmations Account Models Trade Types Accrual Interest Funding Projection Client statement Reports Outgoing feeds Collateral Others Booking of Entitlement/ Dividend
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Note: Partially supported indicates absence of Cash Processing requirements only. All security processing requirements against the Requir Ref #s are fully supported in HCL Solution. Partially supported items will undergo Enhancements over Base Product
Not Required indicates that these were clarified as "not required" from HCL "No" indicates these are new requirements which are currently not available, but need to developed as a new module and in
Delivered by HCL Base Product - Fully/Partially enhancement/Not Supported/ Not Required No Partially Partially Yes Yes Yes No Yes Yes Yes No Not required Partially Partially Partially Partially Yes Partially incoming interfaces integration outgoing interfaces integration
FPS
Cash/Sec
y. All security processing requirements against the Requirement ndergo Enhancements over Base Product
ailable, but need to developed as a new module and integrated to base HCL solution
Core Build Effort FP (1 FP = 1 Manday) % of Core Build Effort over total Project duration (average) Total Project Effort (including Req Gathering, Design, Build, Integration, Training & Documentation, Testing, Deployment) - in FP / Mandays No of days in a month Total Man-months for development Contingency Factor = 15% Mandays Final Rate card for SGP, per month in USD- assumed Cost of Customization & Enhancement (without adding Implementation Services) Implementation Services @ 15% on Base Product Cost of USD 350K Add: Base Product Cost Total Pricing
Team Size Required to execute this project Onsite coordinator Project Manager - onsite / offshore SME / Solution Architect Custody & Asset Services BA's with SWIFT Implementation capabilities Technical Architect + 2 Technical Leads ( all above 6+ years experience) Testers - Functional + 2 Technical Testers (capability to test SWIFT Messages with simulator experience needed) Total (Arvind - Balaji to verify this)
1140 40% 2850 22 129.5454545 19.43181818 148.9772727 3000 446,931.82 52,500.00 499,431.82 350,000.00 849,431.82
1340
2589
1 1 1 2 3 3 11
mandays
2712
15/month 21 days
Weeks 1 1 6 3 2 13
1st Aug
31st Oct