search

mojaloop / project

Repo to track product development issues for the Mojaloop project.
Other
24 stars 15 forks source link

Mowali KYC Proposal - High level Approach #1949

Closed godfreykutumela closed 3 years ago

godfreykutumela commented 3 years ago

Goal:

As a hub operator

I want to ensure that participants comply with the KYC and AML-CFT guidelines issued by the regulators of the participants and especially The Financial Action Task Force (FATF), that is the global money laundering and terrorist financing watchdog. As a technical partner to Electronic Money Institution, we are regulated directly by the Central banks. But because the MNOs have to respect regulations in place in their different countries in regarding financial crimes, Mowali have to develop an AML program and make sure all regulations are taken in consideration

so that Mowali can ensure that activity continues smoothly and avoids the risk of non-compliance of the regulation by a participant, Mowali is looking in the way to have real-time monitoring of all transactions and reporting any incident to the participants. Also to be able to pull an AML/CFT report from the platform.

Acceptance Criteria:

Complexity: High

Uncertainty: Medium

Tasks:

Done

Pull Requests:

Follow-up:

Dependencies:

Accountability:

godfreykutumela commented 3 years ago

Hi @JustusOrtlepp Please have a look at this urgent AML request from Mowali and let me know if this something planned in the near future on the FRM work.

mjbrichards commented 3 years ago

Hi Godfrey, I might have misremembered the AML requirements, but as far as I recall them they relate to a) activity on particular accounts and b) activity by particular people or organisations. With respect to the first, Mowali (or any interop switch) will only have a very partial view of the activity on any given account, since all on-us activity on that account (that is, transfers where both parties belong to the same DFSP) will be unknown to the switch. The Mowali hub will therefore be unable to add any information relating to activity on a particular account which is not already known to the DFSP which owns it. Whether the activity is a consequence of a Mowali transaction or not, the owning DFSP will know about it.

The situation is somewhat different with respect to the second question. Mowali (and Mojaloop in general) has no interest at present in the person who owns an identifier (in Mowali's case, a MSISDN or a merchant ID). All it wants to know is which DFSP owns the identifier: it assumes that the responsibility for KYC on the identifier belongs to the DFSP, and there is no central checking that, for instance, I haven't registered a different phone with every DFSP in Mowali as part of my criminal activities. I think that @JustusOrtlepp and his team may be looking at this question as part of their FRM work.

We can divide Mojaloop identifiers into three different classes. The first class directly represents a transaction account at a DFSP. This includes IBANs, some types of account number, and MSISDNs in schemes like Mowali which at present only include MNOs. The second class does not directly represent a transaction account, but does directly represent a person. This class includes, for instance, National ID numbers and passport numbers. The third class represents nothing apart from something which is recognisable by a DFSP: for instance, aliases or metchant IDs.

For identifiers in the first class, it should be reliable that a single identifier only represents a single account. There are problems of duplication here, particularly with MSISDNs, which can be used by third party MMSs and by banks as well as by MNOs to identify accounts. But generally they offer the most reliable mapping between identifiers and accounts.

For identifiers in the second class, an identifier should be reasonably reliable as an index to an account, provided that the scheme has a reliable way of verifying that an identifier is correct. This may well be true for National IDs, for instance, but may be less so for passport numbers. In general, however, it should not be possible for a single ID of this type to be usable by more than one DFSP; but there is no obvious way for the switch to be confident that I haven't opened an account with one DFSP using my MSISDN, and an account with another DFSP using my national ID.

With the third class of identifier, all bets are off. It would be up the individual scheme to invent ways of preventing me inventing 35 different aliases and registering them with the scheme, with one or more DFSPs. There is nothing at present in the code to prevent this happening, though scheme rules might forbid it and individual schemes might design and implement ways of enforcing the prohibition.

TIPS have looked at this question with respect to the question of identifier types which do not directly represent transaction accounts. Their solution for Merchant IDs and aliases is to require the DFSP to register the transaction account and (for merchant IDs) the Tax Identification Number for each merchant ID or alias requested. This should ensure that multiple merchant IDs and aliases can be picked up by the system, particularly if the system were extended to require a national ID or passport number for each alias. So that would enable a scheme like Mowali to ensure that they had a clear view of multiple accounts owned by the same entity; however, it would not in itself solve the problem of on-us transactions.

To solve this problem, there would need to be some kind of structure which would, for example, enable Mowali to request information on on-us transfers for specific accounts (e.g. where multiple accounts are registered to the same person.) We would need to think further about how that might work.

Sorry this is a bit of a braindump, but I wanted to give you some material for Friday. I'm happy to discuss further if you'd like to set something up.

godfreykutumela commented 3 years ago

@MichaelJBRichards This is great initial positioning with regard to AML on the current Mojaloop architecture and flows. To advance this, I have requested a meeting with a border audience at Mowali(C level Business and Tech) and will let know if is on and we are aiming for Friday at 12pm GMT - hope it will be okay with you. I will also invite you @JustusOrtlepp

godfreykutumela commented 3 years ago

Next step is to hold a workshop with Mowali and this is set for first week in Feb 2021.

godfreykutumela commented 3 years ago

A meeting to discuss Mowali's requirements in detail is set for the 9th Feb 2021.

godfreykutumela commented 3 years ago

Comments from Justus

Hi Godfrey,

As a team we would be delighted to engage and understand their requirements further, and make sure that their needs are properly reflected in the platform. But we also need to be very careful creating expectations from the FRM workstream that we are in a position to support Mowali in the short term. An existing commercial solution would be their best short term solution – but it will also require a level of additional data being added to meet their stated needs.

Given the background work already undertaken, a blanket “Address FATF requirements” is probably 2 years away, and core elements of that are not currently in scope of what we are working on for our MVP; however some of their requirements could be addressed in the next 6 months.

To help everyone understand, FATF has a balance of Transaction Monitoring as well as Identity and income validation and checking. The FRM work is focussed on the transaction monitoring, as the sources of information required to support income validation and checking are too far removed from the work underway. As Michael pointed out, even for transaction monitoring the whole picture of a user is hidden from the switch, because of on-us transfers (as well as possibly any existing point-to-point agreements). So there is no way that Mojaloop alone can realistically provide insight that is not already addressed by the DFSPs systems.

The validation of users also requires access to external services, and access to sufficient data to vet. We will be assessing elements of this entity resolution in the next PI.

Regards Justus

godfreykutumela commented 3 years ago

Mapping of the FRM work to Mowali's compliance requirements.docx

godfreykutumela commented 3 years ago

Folks,

I was thinking about the discussion we had last week about Mowali's compliance requirements, and it occurred to me that it might be possible to solve them in a way which would be lightweight and quick to implement. It rests on the ideas, first, that Mowali doesn't have to do (much) more than meet the KYC requirements that are also imposed on its DFSPs (after all, it's not a national interoperability scheme); and, second, that the regulator(s) would be sympathetic to the idea that Mowali doesn't have any independent access to the customers who participate in its transfers, and that it's therefore legitimate for Mowali to rely on the information that its participants hold about their customers.

If these ideas are true, then the attached presentation proposes a way of complying with the regulations which would be simple and quick to implement. It could be done in an MVP way (as described in the presentation,) I would estimate, in one or two months; though of course I would defer to the architects and developers on the ground.

Obviously, this is nothing like a proper FRM system as Justus describes it; but it did occur to me that it might be suitable if deadlines were urgent and the immediate requirements relatively simple. Let me know what you think.

Yours, Michael

KYC Compliance In Mowali.pptx

mdebarros commented 3 years ago

@godfreykutumela, @MichaelJBRichards in summary:

  1. ALS Services on a GET /parties will now fetch both Payer and Payee information <-- How will we do this? I.e. is it just a general config that both Payer and Payee KYC info must be fetched at all times, or will we implement some kind of rule (and will this be based on participant information from the switch's records)?
  2. The PUT /parties will contain the additional KYC information in either
    1. Extension Fields
    2. Extend API to include additional KYC information

Alternatively, why do we not provide the "Payer" KYC details as part of the quote?

IMO, the GET /parties request is purely "discovery"....any kind of compliance checks should be done as part of the quote stage (if they are needed), as such.....the KYC info should only be required at that stage.

mjbrichards commented 3 years ago

@mdebarros: 1) This is not a single call to GET /parties: the switch will send a separate GET /parties to the payer DFSP. We could do this either with config or with a rule (see this morning's fascinating discussion...)

2) It would certainly be possible to create a scheme rule that the payer DFSP must include the payer's KYC details in the quote request, and a switch rule to check that they were there and reject the quote request if they were not. This would involve exposing the payer account's KYC information to the payee DFSP as part of the quote, which might or might not be desirable. However, as you say, it would be an alternative.

The switch can ask for the payer's details at any point in the process. I would expect this to happen at the quote stage; but it could happen elsewhere if required.

godfreykutumela commented 3 years ago

Hi, @MichaelJBRichards I suggest we don't the Payer KYC info to Payee DFSP as part of the quote but rather keep it within the switch and make it available upon request - even if it offline. I think Mowali is currently handling the same in the P2P with forex flow wherein the Payee DFSP send through the Payee KYC to the Switch and it is not forwarded to the Payer DFSP.

godfreykutumela commented 3 years ago

We provided Mowali with an interim solution approach to address their urgent AML/KYC compliance requirement. We need their approval before we can detail it further, so I am busy facilitating internal review at Mowali. The FRM can provide a solution in 12-18months time, whereas Mowali is under pressure from their new settlement partner Ecobank to comply with their compliance requirements.

godfreykutumela commented 3 years ago

Followed meeting with Mowali scheduled for 31 March 2021 at 12 pm UTC - Confirmed Attendees from OSS ( me and Michael) and from Mowali - Mai, Zana and Kadidia.

godfreykutumela commented 3 years ago

Meet with the Mowali team (Pierre, Maimouna, Zana and Kadidia) on the 31 March to present and clarify a few questions regarding the current proposal and @MichaelJBRichards will update the proposal with agreed changes by the 19th of April when he comes back from vacation.