Settlements BC - Ref Arch Documentation

[mdebarros]

Goal:

As a stakeholder

I want to be able to consult the Reference Architecture documentation regarding the Bounded Context "Settlements"

so that I can better understand the BC use cases and it's relation with the rest of the Reference Architecture

Acceptance Criteria:

• TBD

---

Tasks:

• Write documentation [ @mwmentor ]
• Review documentation [ @MichaelJBRichards ]

Done

• Acceptance Criteria pass
• TBD

Pull Requests:

• TBD

Follow-up:

• N/A

Dependencies:

• N/A

Accountability:

• Owner: TBC
• QA/Review: TBC

[mjbrichards]

"Trigger creation of window" should be "Close existing window".
The sequence of events should be:

• Rename requested window

[mjbrichards]

Oh, OK. We should just delete "Trigger creation of window", then. And the sequence of events for "Trigger closing of window" should be:

• Rename requested window

[mjbrichards]

Answer to the question: "what if no window is found?": The settlement model structure for each implementation should include a default model (i.e. a model without criteria for inclusion.) If there is no default model, this is an unrecoverable error.

[mjbrichards]

For TransferCommittedFulfilled, add:

• If the settlement window doesn't exist:
• Create an account for it in AnB.
• Add it to the settlement window matrix.

[mwmentor]

Cool, I will do this update this afternoon. Thanks Michael :-)

[mwmentor]

Hi Michael: I realised subsequent to commenting above that these changes need to be reflected in the Deferred Net Settlement UC on Miroboard. I will chat to @pedrosousabarreto about it today and ask him to revert to you. Thanks.

[mwmentor]

Hi Michael: Please could you confirm whether the following description works for the "DFSP Issue Consent" workflow? If it does not, please could you make change suggestions. Thanks. :-)

"The workflow provided by this UC supports authorized DFSP Account Holder consent requests to Account Holders requesting permission to link Account Holder account details to a PISP User Account in order to enable the PISP to act on behalf of the DFSP Account Holder."

[mjbrichards]

Er, @mwmentor, isn't this about PISP? Did you mean @lewisdaly?

[mwmentor]

Hi Michael - yes, sorry... losing my marbles a bit... 😄

[mwmentor]

During discussion today, the DNS UC has been updated extensively: DNS Settlement UC no longer supports manual creation of Settlement Batches (were Windows), Settlement Windows have been revised out and Settlement Batches that are rules based (i.e.: created by the BC rules) has been added. Further, every Settlement Batch creation process also triggers creation of a corresponding Settlement and Position Account pair in the A&B BC. The Settlement Batch can be closed manually for emergency reasons, and also for Settlement purposes. Participant DFSPs are required to accept the quotes for their transactions in the Transfer's Matrix, and once they do so, required payment funds are reserved against their A&B BC Settlements Account. Once all participants have accepted the Settlement Matrix, the Settlement Batch is closed and the state is recorded and noted in the participant DFSP accounts, and the Settlement is noted as closed. The corresponding A&B BC Settlement Accounts (Settlement and Position) are also closed and their state recorded appropriately.

I think that's a reasonably correct understanding? @MichaelJBRichards

[millerabel]

I’d like to understand this better. As I read below, are you suggesting that multilateral agreement of settlement batches will be sought before settlement can be executed? The central design of Mojaloop, and one of its most important principles, is that settlement is performed by automatic pass through processing, without active involvement of participants. This is not an ACH or an RTGS! The settlement agent has the full authority to trade the participants settlement funds to balance outstanding positions. And settlement can be performed at high-speed, 24/7, without seeking multilateral agreement or even acknowledgment of the participants. DFSPs receive a report, following settlement, that can be used for automatic reconciliation. What is meant by the statement, …

Participant DFSPs are required to accept the quotes for their transactions in the Transfer's Matrix, and once they do so, required payment funds are reserved against their A&B BC Settlements Account. Once all participants have accepted the Settlement Matrix, the Settlement Batch is closed and the state is recorded and noted in the participant DFSP accounts, and the Settlement is noted as closed.

— Miller On Oct 19, 2021, at 4:25 AM, Michael Wagener ***@***.***> wrote:  During discussion today, the DNS UC has been updated extensively: DNS Settlement UC no longer supports manual creation of Settlement Batches (were Windows), Settlement Windows have been revised out and Settlement Batches that are rules based (i.e.: created by the BC rules) has been added. Further, every Settlement Batch creation process also triggers creation of a corresponding Settlement and Position Account pair in the A&B BC. The Settlement Batch can be closed manually for emergency reasons, and also for Settlement purposes. Participant DFSPs are required to accept the quotes for their transactions in the Transfer's Matrix, and once they do so, required payment funds are reserved against their A&B BC Settlements Account. Once all participants have accepted the Settlement Matrix, the Settlement Batch is closed and the state is recorded and noted in the participant DFSP accounts, and the Settlement is noted as closed. The corresponding A&B BC Settlement Accounts (Settlement and Position) are also closed and their state recorded appropriately. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.