Skip to content
Snippets Groups Projects
Commit a3ef10a9 authored by Eric D. Schabell's avatar Eric D. Schabell
Browse files

Added right payments architecture as example.

parent eb7b850d
No related branches found
No related tags found
No related merge requests found
Pipeline #1527001849 passed
= Payments
Eric D. Schabell @eschabell, Ramon Villarreal @rvillarr
:homepage: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples
:imagesdir: images
:icons: font
:source-highlighter: prettify
:toc: left
:toclevels: 5
This architecture covers the use case around using payments architecture in the financial services domain. An offering
of (near) real-time payments lets businesses, consumers, and even governments send and accept funds that provide both
availability to the recipient and instant confirmation to the sender. Enabling real-time - or at least faster - payments
that improve the speed of online payment experiences to customers has the potential to give banks a greater opportunity
to win, serve, and retain their customers. By building solutions that capture real-time payment business, banks also
can drive higher payment volumes, ideally at lower costs as well as engage new customer segments.
*Use case:* Financial institutions enabling customers with fast, easy to use, and safe payment services available
anytime, anywhere.
--
image:https://gitlab.com/redhatdemocentral/portfolio-architecture-examples/-/raw/main/images/intro-marketectures/payments-marketing-slide.png[750,700]
--
== The technology
--
image:https://gitlab.com/redhatdemocentral/portfolio-architecture-examples/-/raw/main/images/logical-diagrams/fsi-payments-o11y-ld.png[750,700]
--
* The following technology was chosen for this solution:
** *Chronosphere* is the only observability platform that controls for the speed, scale, and complexity that comes with
the technology and organizational changes associated with a cloud native and DevOps world. Chronosphere helps engineers
detect and resolve infrastructure and application issues before they affect customer experiences and the bottom line.
Chronosphere helps teams increase customer satisfaction, and gain competitive advantage - all while controlling costs.
** *Red Hat OpenShift* is an enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy.
It provides a consistent application platform to manage hybrid cloud, multicloud, and edge deployments.
** *Red Hat OpenShift Runtimes* helps organizations use the cloud delivery model and simplify continuous delivery of
applications, the cloud-native way. Built on proven open source technologies, it also provides development teams
multiple modernization options to enable a smooth transition to the cloud for existing applications.
** *Red Hat 3scale API Management* makes it easy to manage your APIs. Share, secure, distribute, control, and monetize
your APIs on an infrastructure platform built for performance, customer control, and future growth.
** *Red Hat AMQ Streams* is a massively scalable, distributed, and high-performance data streaming platform based on
the Apache Kafka project. It offers a distributed backbone that allows microservices and other applications to share
data with high throughput and low latency.
** *Red Hat Integration* is a comprehensive set of integration and messaging technologies to connect applications and
data across hybrid infrastructures.
** *Red Hat OpenShift Data Foundations* is software-defined storage for containers. Engineered as the data and storage
services platform for Red Hat OpenShift, Red Hat OpenShift Data Foundation helps teams develop and deploy applications
quickly and efficiently across clouds.
** *Red Hat Enterprise Linux* is the world’s leading enterprise Linux platform. It’s an open source operating system
(OS). It’s the foundation from which you can scale existing apps—and roll out emerging technologies—across bare-metal,
virtual, container, and all types of cloud environments.
== Immediate payments
--
image:https://gitlab.com/redhatdemocentral/portfolio-architecture-examples/-/raw/main/images/schematic-diagrams/fsi-payments-immediate-payments-sd.png[750,700]
image:https://gitlab.com/redhatdemocentral/portfolio-architecture-examples/-/raw/main/images/schematic-diagrams/fsi-payments-immediate-payments-data-sd.png[750,700]
image:https://gitlab.com/redhatdemocentral/portfolio-architecture-examples/-/raw/main/images/schematic-diagrams/fsi-payments-immediate-payments-o11y-data-sd.png[750,700]
--
The overview of immediate payments starts with a payment request through the front facing payments API, which is then
validated, then used to trigger an event in the payments event stream. At this point we assume that all the checks
are triggered, which is not always the case, so that we can describe all of the detailed architectural elements in
this diagram. From the events stream both anti-money laundering and fraud detection services are used to ensure this
is a valid payment request and not something negligent. If they clear those checks, an event triggers the clearing
of the payment to process it through those services before routing services are event triggered to send the final
payment instructions ot the external payments network.
Cloud native observability for your immediate payments architecture is provided by open source standards based
Chronosphere, using it's Collector component. This is a standalone component whose main function is to discover and
scrape a Prometheus server that's exposed by your applications. It forwards any discovered data to the Chronosphere
service through a secured connection. If the Collector can't scrape certain jobs or components, you can manually push
metrics to it. In addition to ingesting metrics, the Collector can also receive traces from your services, such as
OpenTelemetry (OTel) spans and other popular open source formats like Jaeger and Zipkin.
The first diagram is of a network based architecture, the second focuses on the data flow, the third includes the
deployment of the Collector either as a DaemonSet in OpenShift or as a sidecar solution.
== Anti-money laundering (AML)
--
image:https://gitlab.com/redhatdemocentral/portfolio-architecture-examples/-/raw/main/images/schematic-diagrams/fsi-payments-anti-money-laundering-sd.png[750,700]
--
This example zooms into the first diagram, looking at the anti-money laundering element in more detail. For this reason
the payments API is left out of the diagram for focus on event streaming and the anti-money laundering activities in
this architecture. We see that the events stream triggers the start of an anti-money laundering check, which is taking
a look at the payment transaction to score it and add labels as needed. These are scoring and labelling decisions are
based on the use of a AI/ML model that is shown in the bottom right being updated and trained using know your customer
data maintained in external systems at a financial institution. Once the sorcing is done, rules are used to ensure that
the payment is not transgressing any anti-money laundering rules. If it is a good payment request, that event is sent
back to the event stream for processing through to payment as described in the previous diagrams. If bad intent
is detected, an event is sent the to malicious activity streams element so that a case can be opened for further
investigation and suspicious activity processes can be started to report the final outcomes.
== Fraud detection
--
image:https://gitlab.com/redhatdemocentral/portfolio-architecture-examples/-/raw/main/images/schematic-diagrams/fsi-payments-fraud-detection-sd.png[750,700]
--
This example zooms into the first diagram, looking at the fraud detection element in more detail. For this reason
the payments API is left out of the diagram for focus on event streaming and the fraud detection activities in
this architecture. We see that the events stream triggers the start of a fraud detection check, which is taking
a look at the payment transaction to score it and add labels as needed. These are scoring and labelling decisions are
based on the use of a AI/ML model that is shown in the bottom right being updated and trained using know your customer
data maintained in external systems at a financial institution. Once the scoring is done, rules are used to ensure that
the payment is not transgressing any fraud rules. If it is a good payment request, that event is sent
back to the event stream for processing through to payment as described in the previous diagrams. If potential fraud
was detected, an event is sent the to malicious activity streams element so that a fraud prevention process starts. The
eventual outcome of this process is delivered back to the event steams for processing only if the detection was
determined to be wrong.
== Financial calculations
--
image:https://gitlab.com/redhatdemocentral/portfolio-architecture-examples/-/raw/main/images/schematic-diagrams/fsi-payments-calculations-sd.png[750,700]
image:https://gitlab.com/redhatdemocentral/portfolio-architecture-examples/-/raw/main/images/schematic-diagrams/fsi-payments-calculations-data-sd.png[750,700]
image:https://gitlab.com/redhatdemocentral/portfolio-architecture-examples/-/raw/main/images/schematic-diagrams/fsi-payments-calculations-o11y-data-sd.png[750,700]
--
The financial calculations diagram lays our an architecture that is in the payments realm, but more designed to
determine the payment to be requested through a billing system of a customer. The request for calculating a payment
comes into the architecture in the form of a message from the front facing API's. This message is processed through
various message queues, first validation of the request, then processed through detailed calculations using rule
services to determine the payment needed, through integration services connecting the organisation to their eventual
billing systems to issue the payment invoice.
Cloud native observability for your immediate payments architecture is provided by open source standards based
Chronosphere, using it's Collector component. This is a standalone component whose main function is to discover and
scrape a Prometheus server that's exposed by your applications. It forwards any discovered data to the Chronosphere
service through a secured connection. If the Collector can't scrape certain jobs or components, you can manually push
metrics to it. In addition to ingesting metrics, the Collector can also receive traces from your services, such as
OpenTelemetry (OTel) spans and other popular open source formats like Jaeger and Zipkin.
The first diagram is of a network based architecture, the second focuses on the data flow, the third includes the
deployment of the Collector either as a DaemonSet in OpenShift or as a sidecar solution.
== Download diagrams
View and download all of the diagrams above in our open source tooling site.
--
https://redhatdemocentral.gitlab.io/portfolio-architecture-tooling/index.html?#/portfolio-architecture-examples/projects/fsi-payments.drawio[[Open Diagrams]]
--
\ No newline at end of file
= Point of Sale
Eric D. Schabell @eschabell, Iain Boyle @iainboy
:homepage: https://gitlab.com/redhatdemocentral/portfolio-architecture-examples
:imagesdir: images
:icons: font
:source-highlighter: prettify
:toc: left
:toclevels: 5
Retail is the process of selling consumer goods or services to customers through multiple channels of distribution to
earn a profit. A point of sale, or point of purchase, is where you ring up customers. When customers check out online,
walk up to your counter, or pick out an item from your stand or booth, they're at the point of sale. Your point-of-sale
system is the hardware and software that enables your business to make those sales.
*Use case:* Simplifying and modernizing central management of distributed point-of-sale devices with built in support
for container based applications.
--
image:https://gitlab.com/redhatdemocentral/portfolio-architecture-examples/-/raw/main/images/intro-marketectures/pos-marketing-slide.png[750,700]
--
== The technology
--
image:https://gitlab.com/redhatdemocentral/portfolio-architecture-examples/-/raw/main/images/logical-diagrams/retail-pos-ld.png[750, 700]
--
* The following technology was chosen for this solution:
** *Red Hat OpenShift* is an enterprise-ready Kubernetes container platform built for an open hybrid cloud strategy.
It provides a consistent application platform to manage hybrid cloud, multicloud, and edge deployments.
** *Red Hat Ansible Automation Platform* is a foundation for building and operating automation across an organization.
The platform includes all the tools needed to implement enterprise-wide automation.
** *Red Hat Integration* is a comprehensive set of integration and messaging technologies to connect applications and
data across hybrid infrastructures.
** *Red Hat Satellite* is an infrastructure management product specifically designed to keep Red Hat Enterprise Linux
environments and other Red Hat infrastructure running efficiently, with security, and compliant with various standards.
** *Red Hat Ceph Storage* is an open, massively scalable, simplified storage solution for modern data pipelines.
Engineered for data analytics, artificial intelligence/machine learning (AI/ML), and emerging workloads, it delivers
software-defined storage on your choice of industry-standard hardware.
** *Red Hat Enterprise Linux* is the world’s leading enterprise Linux platform. It’s an open source operating system
(OS). It’s the foundation from which you can scale existing apps—and roll out emerging technologies—across bare-metal,
virtual, container, and all types of cloud environments.
== Point of sale image delivery
--
image:https://gitlab.com/redhatdemocentral/portfolio-architecture-examples/-/raw/main/images/schematic-diagrams/retail-pos-sd.png[750, 700]
--
The above diagram demonstrates a solution to deliver images of point of sale devices and store applications across
diverse retail landscapes. It tackles the challenges of standardizing how to support both legacy infrastructure needs
at the point of sale, as well as positioning a retail organization for the cloud native development future of their
business.
The SKU Catalog is maintained with available items for sale in the running inventory. The sales data cache is where
all sales activities are collected and held for sharing to the retail organization. Point of sale is an onsite
application and is the main focus of providing an end point application image pipeline for use throughout the retail
organisation.
The store server is a part of the infrastructure that hosts the elements needed to facilitate on site point of sale
image pipelines and the daily management of communication, sales data, and stock control information. The SKU Catalog
takes input from each point of sale in the store. The image cache hosts the retail organizations centrally developed
collection of point of sale images.
== Download diagrams
View and download all of the diagrams above in our open source tooling site.
--
https://redhatdemocentral.gitlab.io/portfolio-architecture-tooling/index.html?#/portfolio-architecture-examples/projects/retail-pos.drawio[[Open Diagrams]]
--
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment