I have concerns about how DCR is being implemented in the SD application.

• DynamicReferenceForWorkClass (PegaCardSDAcquirer) - sets some issuer specific values for the  Claim, Dispute, and Debit value groups, and then sets BaseMasterCard and MCWorkClassList(1) to acquirer values.
• DynamicReferenceForWorkClass (PegaCardSd) - sets issuer specific values for for the Claim, Dispute, and Debit value groups, and then applies a data transform for SetMasterCardClassNames and SetVisaClass names.
• SetMasterCardClassNames - sets issuer specific values for BaseMasterCard, and then adds issuer specific values for MCWorkClassList(1, 2, and 3).
• SetVisaClassNames - sets the BaseVisa value group to an issuer specific class.

Our implementation has several flavors...we have an Issuer specific application for dealing with issuer batch queues, and we have an acquirer specific application for dealing with the acquirer batch queues.  In both of these scenarios, the DCR set up by Smart Disputes seems to generally be ok.

We also have a unified disputes application, which contains all rulesets in the application stack, both issuer and acquirer, and this is where my concern arrises.  If there is any shared DCR property name (ex: MCWorkClassList) or any generic type of definition (ex: .DynamicReferenceForWorkClass(Debit), (Dispute), (BaseMasterCard), (BaseVisa)), then the DCR that is defined is going to be inconsistent, depending on which ruleset at my implementation layer sits on top of the stack (ex: if the acquirer ruleset is on top, I'm going to get acquirer DCR, and if issuer is on top, I will get issuer DCR).

I would feel much more comfortable if the DCR definitions were issuer/acquirer specific (ex: if there unique definitions for BaseMasterCardIssuer, BaseMasterCardAcquirer, MCWorkClassIssuerList, MCWorkClassAcquirerList, etc.) 

At this point, I don't know how I am supposed to configure these, in a way where I have correct DCR values for 100% of my scenarios.  For example, if I define the .MCWorkClassList(1) value in the acquirer ruleset to be "MyCo-Acquirer-Dispute-MC" that will be perfectly valid for the acquirer application, but not valid for the unified application...if a unified disputes application rule references .MCWorkClassList() in a context that is supposed to run issuer rules...it will be wrong.

Are these concerns/issues something that the SD team has taken into consideration?  I could potentially override any usage of the DCR to instead use my own custom mappings, however doing so will increase future maintenance, as I will need to monitor the overridden rules.  Additionally, I will need to monitor any time that SD adds new references to these properties, so I can change them to use the issuer/acquirer specific values that I would define.