Notes from Participation Tools Worksteam Weekly Sync Call
- RPi demo - 10tps sequential easily achieved with very basic sequential test from TTK with mock DFSP backend.
- This is addressing smaller DFSP use cases
- Payment Manager adoption; there is good stuff there e.g. MCM, management API, onboarding UX etc…:
- We need a plan to close the gaps on docs + test coverage.
- Range of solutions to cater to different “classes” of DFSP:
- Todo: Define these classes properly:
- Do they self host their CBS? Or use SaaS?
- Do they have IT skills to install and configure?
- Small:
- Option1: low cost “server” hardware e.g. RPi or mini-itx etc…, on-prem, docker-compose+systemd, linux OS firewall
- Minimal redundancy requirement, can accept some downtime.
- Todo: figure out UI requirements and how to deliver them efficiently; pm4ml UI? Or something else?
- Pros: one off cost
- Cons: needs installation and setup.
- Could be PISP only via OpenBanking SDK.
- No need for CBS integration.
- Option2: aggregator model
- Do they have their own CBS, bank accounts etc…?
- ITK hosted by an aggregator?
- Pros: simple
- Cons: recurring costs?
- Possibly suits “micro” DFSPs.
- Could be PISP only via OpenBanking SDK.
- No need for CBS integration.
- Option1: low cost “server” hardware e.g. RPi or mini-itx etc…, on-prem, docker-compose+systemd, linux OS firewall
- Mid-range:
- Option1: mid-level “server” hardware
Some redundancy requirements, less willing to accept downtime.
- Todo: Find out typical SLAs.
- More “enterprise” type features for management and monitoring.
- Possibly integration into existing IT management stack (metrics, observability, alterting)
- Reporting features?...probably same across the board.
- Option 2: 3rd party hosting of integration layer Cloud or on-prem
- Typically requires VPN between integration layer and CBS/backends. Not “mojaloopy”.
- VPN seen as a cost barrier for small DFSPs in Mojaloop principles….is it ok for larger DFSPs?
- This is ripe for challenging!
- Pros: simple
- Cons: recurring cost
- Option1: mid-level “server” hardware
Some redundancy requirements, less willing to accept downtime.
- Large:
- Option1: high-end “server” hardware (possibly existing on-prem private/public/hybrid cloud)
- High resilience, reliability, redundancy requirements. Strong need for enterprise grade management, monitoring, alerting features.
- High security bar.
- Scalable performance requirement.
- Option2: 3rd party hosting of integration layer
Cloud or on-prem
- Strong need for enterprise grade management, monitoring, alerting features.
- High security bar.
- Scalable performance requirement.
- Option1: high-end “server” hardware (possibly existing on-prem private/public/hybrid cloud)
- Common:
- Fast iteration to make use of scheme enhancements (upgrades, more traffic etc…):
- CI for integration dev work: change -> test -> release
- Common requirements:
- “Simple” integration with backends:
- Low-code?
- Efficient testing and validation not just during initial setup but ongoing.
- Dev, UAT, Production testing? CI?
- Excellent security.
- Low cost.
- Efficient use of resources.
- Ability to “see” what has happened (debugging, reporting)
- Support???!!!
- “Simple” integration with backends:
Please find all meeting notes in this doc: https://docs.google.com/document/d/1FCwkin-2JE4OwjVk9wb3xAjs6aDywgxTdGbg4tJJYsQ/edit?usp=sharing
Top comments (0)