[2:20 PM]
paymentsSCVcommunication hubbatching for goddexloan acquisition re-try of essential services (e.g. loan agreement, etc)data ETL related processes
[2:20 PM]
example of more complicated payments problem - card payments
[2:21 PM]
close to real time service can notify us (or we can poll it) to get confirmation a card payment was successfully authorised by a customer (typically loan collections)
[2:22 PM]
the actual payment comes several days later and there is potentially no further third party notification available - just that a payment arrived - but payment has some given reference or we recognise it as coming from a given sort code / account number etc
[2:23 PM]
payments are also typically collated and one single payment is made into our account corresponding to many customer card payment authorisations as opposed individual payments
[2:23 PM]
idea:
[2:24 PM]
at the time of initial notification, create an appropriate message on a queue but do not process yet
[2:24 PM]
when an payment arrives only then process corresponding messages on the first queue
[2:48 PM]
Systems:
[2:48 PM]
SalesForce - Pranay can explain options
[2:48 PM]
Goddex - Marek Susicky can explain
[2:49 PM]
Mambu - the access is via API or Webhooks - Francois can explain
[2:50 PM]
E6 - expect to integrate via Mosaic but vacuumlabs can explain
[2:51 PM]
Mobile App / Graph QL - expect to integrate via Mosaic but vacuumlabs can explain
[2:51 PM]
Intellect - Francois can explain
[2:51 PM]
ETLs / DataLake - Paul Shortrige and Mohit probably best ppl to consult
[2:52 PM]
like 1
[2:53 PM]
Loan Acquisition in general - not sure yet about exact use case but probably all relayed via Mosaic
[2:54 PM]
examples of asynchronous third party notifications: GBG face and document recognition, Account Score open banking etc
[2:56 PM]
in acquisition journey, post Goddex decision communicated to customer we may want to use queues to push information from the Goddex output file to various systems and data storage solutions (e.g. SF, S3, RDBMS etc)