Handling of Client Registrations and Ledger Account/Balances from CSD

, ,
1

Imported from previous forum

2

If you are simply looking for reference data related to parties and accounts, you can start with PartyDetail* messages (look at the latest FIXimate: http://www.fixtradingcommunity.org/FIXimate/FIXimate3.0/latestEP/index.html). PartyEntitlements then lets you convey who is allowed to do what.

Withdrawals and deposits of collateral may also be covered by the Collateral* messages which carry a Parties block to specific accounts.

3

Hi All,

If you’re using FIX to interface with a CSD, are their specific message types that an exchange can use in order to intra-day handle;

a. Client Registrations : Receive Registration Account details (Client/Status/Firm/Account Type etc…) per Client from CSD?

b. Ledger Accounts : Receive Individual Ledger Account updates per Registration (such as withdrawals, deposits etc…) from CSD?

I have been looking at messages such as Registration Instructions(35=o) and Position Report (35=AP) for this but it seems they don’t fit the exact requirements.

Thanks,
Hiran

4

Hi Hiran,

What is missing from the RegistrationInstructions(35=o) and RegistrationInstructionsResponse(35=p) ?
(i.e. “they don’t fit the exact requirements”, which requirements these message do not support?)

If its a matter of permissions, I advise to look at: PartyEntitlements* messages and workflows
[(35=CU), (35=CV), and 35=CZ)]

I hope this helps,
Yuval

5

Hi Yuval,

Firstly, thanks a lot for your feedback.

Actually i’m looking for a message that can be used in an unsolicited manner to communicate reference data related to Registrations such as Status/Client ID/Account Type/etc from a CSD to an Exchange. It seems that RegistrationInstructions(35=o) contains many of the fields required to communicate the above information but im not exactly sure whether the business purpose of this message fits the exact requirements highlighted above. It is actually not a matter of permissions so i don’t think PartyEntitlements can be applied here.

Its said that, business use of this message (35=0) is to submit registration information to a broker/fund manager for an order or allocation.

Regards,
Hiran

6

Hi Hanno,

Good to see your feedback.

Actually, PartyDetailsListUpdateReport(35=CK) message is something im already looking at for ref data reated to Parties (Client/Firm etc...) and Registration Accounts as well. I have been looking at the following EPs in this regard; Although, some external FIX tags may have to be included in this message to achieve the complete set of requirements. 

  • EP 105 - Parties Ref Data Extensions 
  • EP 146 - Parties Ref Data Transactions
  • EP 128 - Risk Limit Extenstions

For withdrawals and deposits, i was looking at the possiblilty of using PartyRiskLimitsReport(35=CM) but it seems there are gaps. I will have a look at the Collateral* messages, i think it might fit in with the requierments. Thanks a lot for point that out.

Regards,

Hiran 

 

7

Hi Hiran, maybe EP193 (http://www.fixtradingcommunity.org/pg/extensions/extension-pack?ExtensionID=EP193) is also relevant in your context. The CME submitted some extensions to the collateral messages for deposits and withdrawals.

8

Hi Hanno,

Thanks a lot for the feedback.

I have two questions that i like to have your thoughts on;

  1.  Instead of using PartyDetails* messages for Registration Accounts, would you recommend using the combination of Registration Instructions (35=o)  and Registration Instructions Response (35=p) as another option? My concern here is whether these messages fit the given business case. We simply require receving the following information from an CSD on an Registration.
    1. Transaction Type ( New/Modify etc..)
    2. Client ID 
    3. Firm ID
    4. Status
    5. Account Type
  2. When it comes to Ledger Accounts, how apprprpiate it is to use Collateral messages to communicate ledger balances? After all, these are simply cash balances for a given participant. On the other hand, would you recommend using PartyRiskLimitsDefinitionRequest (35=CS) to communicate ledger details?


Thanks,

Hiran


9

Hi Hiran,

I am afraid that I neither have the expertise in that specific area nor the time currently to familiarise myself with it. Party* messages are generic in nature and about base data, entitlements and risk limits. Balances are only limits if used to attach certain actions to specific balances. You can then use report messages to inform the counterparty of where he stands relative to the limits defined, i.e. how close he is to a threshhold.

Party* messages are highly generic and look rather complex due to the breadth they are able to cover. Seeing your few details above the actual message layout should be quite simple and should work. I have not worked with the Registration* messages and cannot really comment on their applicability in your case.

Regards,
Hanno.

10

Hi Hanno,

Your feedback is much appreciated. Thanks a lot.

Regards,
Hiran