As a developer, launching a full ecosystem is crucial to test changes properly. However, as dependencies grow, these systems become hard to launch locally. Either because they consume a lot of resources or because they're complex to launch. This pushes developers to either not test properly or rely on shared environments (like dev), which can impact their team members.\nAt Moniepoint, we built a tool that automates resource deployment on a remote cluster, helping developers test features efficiently with minimal configuration.\nIt’s as straightforward as running an eshu workload with a clear, YAML-based workload definition, making the process accessible and manageable.\n\nLaunching a workload\nAfter users install our custom CLI, the first time they run \neshu workload run\n, it generates a random workload name/ID for the run. This ensures users don't clash with other users' workloads on the same cluster. This ID is stored in a local config file, so that we can refer back to it when needed. Next, the system loads local YAML files to create the workload. Users write these files based on the \nScore\n specification. Each YAML file contains 5 parts: apiVersion, metadata, containers, service and resources. As an example, let’s examine this workload file below:\n\n
The apiVersion identifies the version of the workload specification. The metadata portion lets you add annotations and similar metadata to the created resources, and it also specifies the workload name so other workloads can reference it. The containers section includes the images and environment configuration for our app, while the services section specifies which ports we want to expose. The resources part includes the standard resources we want to launch with the workload. Examples include Postgres or MySQL databases, Redis, Kafka, and many others.\nLet’s take a look at another example. The goal is to create a chat app that includes a front-end component, a backend API, and a backend identity service for user identities. The chat app includes a dedicated database and Redis for caching, while the identity service has its own database.\nTo do this, we will launch the workload file above for the identity service, plus another that includes 2 containers for the front-end and backend components, plus a Redis and Postgres resource. The chat file also includes a resource that references the identity workload.\nWhen the eshu workload runs, it merges the files into a single file. Then file references are resolved. Although the example inlines the database script, you can also import it from a separate file with a file reference (${file:initscript.sql}). After this injection, the CLI validates the workload contents against a predefined schema. This helps the user quickly correct mistakes without making any request to the cluster.\nAfter we have a valid merged YAML definition, the CLI sends the workload through an HTTP request to our server in the remote Kubernetes cluster. This lets us create it with a single workload run command.\nWhen the server receives the request, it first creates a namespace named after the workload ID using the Kubernetes API. It then copies any relevant secrets, like the secret used to pull images from the internal Moniepoint Artifactory, into this namespace. \nIn our example, \nfe65c057-45760157-careful-weasel \nis the name of a dedicated namespace where our resources exist.\n\nAfter creating the namespace, Crossplane creates the XWorkload custom resource from our YAML definition in the Score Workloads attribute in the metadata section.\nCreating this resource kicks off the Crossplane composition pipeline we configured.\n\nComposition Pipeline\nThe XWorkload includes the YAML file contents in the Score Workloads section. With it, Crossplane calls our custom function for each workload created, and our function parses that score file and outputs the relevant Kubernetes resources.\nUsing the \ncrossplane function-sdk-go\n, the function needs to implement the RunFunction signature, receive the current request with context, and return the desired resources response.\nOur custom function has 4 main tasks:\nIt reads and parses the YAML file contents from the request (present in the score workloads attribute). \nAfterwards, it adds the required Kubernetes resources (deployments, volumes, …) to the response. It generates a map of environment variables for all resources so it can inject them into the containers. This map includes the database username and passwords, which the function generates automatically. \nThen the containers are added. \nFinally, the required services are created to expose the resources and the proxy so it is reachable from their machine.\nThe main effort with this function was supporting more and more resources over time. Beyond the resource itself, we also added auxiliary components to ensure users had the same functionality across different resources. For example, while PostgreSQL has an easy way to initialise data via setting up a script file when mounting, the Google Spanner emulator does not. So a job is launched after the emulator starts to connect to the pod and run the provided initialisation script. For the user, there is no difference in how to initialise one or the other. To manage this complexity, each resource implements the same interface:\n\n
For our Postgres example above, the implementation will create a secret with randomly generated credentials and store that secret in Vault, create a config map for the SQL initialisation script, create a service to expose the Postgres pod, and create a stateful set that includes a PVC for persisting data. Since this is Postgres, the config map is mounted into the container at\n/docker-entrypoint-initdb.d/init.sql\n, and the generated credentials are passed as env vars to initialise the user. For other resources, like Spanner, a job initialises the data so the user has a unified interface. \nThen the actual function flow is a simple chain of responsibility to generate all the resources:\n\n
With these 2 simple abstractions, we can extend the function to support more and more resources with minimal changes.\nRegarding the environment, each resource adds to the env map. Then, these values are injected into the containers via string interpolation, replacing the string \nresources.[name].[key]. \nFor example, in our demo above, we had a Postgres database resource called pg. The container's environment used \nresources.pg.host\n, \nresources.pg.username\n and \nresources.pg.password\n. \nIn our example, the chat component depends on the identity component, even though they are in different YAML files. To launch them with a single command, we use a special resource called a service that references a workload by name. This service adds the target workload's host and port to the environment, so one container can easily reach another.\nFor the namespace, we can see that pods (deployments) were created for each app (chat with 2 containers and identity with 1) and for each resource. We can also see a proxy that handles traffic redirection from the port-forward to each pod.\n\nThis proxy is created as an Nginx pod with randomised ports for each resource and service from the user YAML file. It sets up the namespace resources so the user can port-forward to them.\nPort forwarding\nAfter creating the XWorload resource, the HTTP request terminates with a success status code. At this point, the resources aren't created yet because the composition hasn't run.\nSo the CLI starts a loop that checks the workload status, with a sensible timeout.\nTo get this status, the CLI uses the workload name mentioned above. It sends a request to the server that identifies the namespace based on that workload name. With the Kubernetes API, it queries all resources in that namespace with the Crossplane label spec.crossplane.resourceRefs and returns their status to the CLI.\nWhen all resources are Running, then the CLI can try to port forward. To port forward, we rely on the nginx proxy that we saw before. The proxy is identified by name in that namespace, and each available port to port forward to is a port on that proxy pod. For each port, the CLI opens a connection and forwards traffic to it. \nLet’s recap:
⁠
⁠We specified what we want to create in the YAML files. As the example files show, the configuration is minimal (no Postgres version specified, no configuration environment variables, no resource or probe specifications). All of these resources were created in a remote cluster (not my local computer) and accessible via port forwarding.\nGenerating dynamic credentials\nCredentials for resources, like database passwords, are randomly generated during provisioning. To make them accessible to the user, we store them in Vault. The CLI includes a command to retrieve a dynamically generated credential from Vault in a single command. \n\nThis is done by configuring the \nVault database secrets engine\n, so when the eshu workload endpoint credential\n \ncommand runs, the CLI requests the control plane server, which uses the Vault API to generate new temporary credentials. \nFor Postgres, for example, we use the \npostgresql-database-plugin\n, and for each dynamic credential we create the user with:\n\nAs with other functionalities, we offer a unified interface. Resources without a Vault secrets engine still work the same way, but the credentials retrieved are static. In that case, it retrieves the credentials generated during resource provisioning.\nClean up of namespaces\nSince these resources are hosted in a remote cluster, we need to ensure they get cleaned up if the user never does it. To ensure that, we have a dedicated server that implements the Kubernetes type-reconciler interface and is associated with the created namespace. \nEach workload resource has an annotation with a target TTL. This server checks whether the namespace has already exceeded the target TTL. If so, it deletes the namespace and vault secrets. \nChallenges & benefits\nOne of the first challenges we ran into was password generation. Crossplane has a render cycle: every 60 seconds, the XWorkload is reprocessed, and any changes are reflected in the cluster. Since we are generating random information, for passwords, for example, this caused the environment to be outdated on the subsequent render cycle. In fact, anything that changed the desired resources on every cycle would cause the pods in the cluster to keep restarting. So it was important to ensure the function would eventually reach a steady state. For password generation, we handled that by checking the existing state of the resources and reusing the password if it was already present.\nAnother challenge was avoiding clashes when so many different resources are being created. We could force users to use different names for every port and container, but that would create a worse experience, especially when workloads are shared across teams. So instead, we decided to compose the names so they need to be unique only within the workload context. This quickly hit the 63-character limit for Kubernetes names. We fixed that by capping each part of the composed name at a specific character length.\nSo what benefits did we actually get from all of this, when compared with something like docker compose or test containers?\nFirst, these workloads are simpler to set up. The resources themselves require minimal configuration, and many defaults are quite sensible for most use cases. Especially when experimenting with a new technology that you might not be quite familiar with, this minimal configuration was helpful. \nAnother benefit is the unified resource interface. As mentioned earlier, you initialise database data via the same input attribute, even if the underlying database doesn't support it out of the box. This simplifies that process so that users can focus on what they are actually working on.\nAll the resources are also being launched in a remote cluster. In heavier apps, this makes quite a difference.\nLastly, all of these definitions are shareable, and a workload can import another. This lets teams more easily spin off full environments for their services. For now, this is a YAML file; in the future, we can build a centralised catalogue.

Automating Kubernetes Infrastructure with Crossplane Functions

Most product teams are sitting on research gold they don't know how to use. They conduct interviews, gather feedback, and collect transcripts, then struggle to turn it all into something the team can actually act on. This is that story, and more importantly, this is the method that changed how I approach qualitative data.\n1. In the Beginning\nYou have carried out your user interviews and research, but what do you do with the messy data you have gathered? How do you make sense of it and use it to make informed decisions?\nI recently conducted user discovery for a new feature we shipped. I grouped users into three categories to understand them at every phase of the journey and to see how each step was perceived.\nI started by gathering users across the different groups and creating a research plan, which I shared with the customer research team for vetting. A process was then set up for interview slots, and the journey began. But in reality, this was only the beginning.\n2. Making Sense of the User Groups\nDividing users into groups wasn't just for structure. It was the only way to get a complete picture of the journey.\nEach group represented a different stage. Group one had completed the process. How did you complete it, and what were the hurdles you had to cross, if any? Group two was still in the process. Are you experiencing similar hurdles or a different one entirely? Group three hadn't started the process. What prevents you from starting this flow?\nUnderstanding every stage helps uncover pain points and how to make the flow seamless for users throughout the cycle. A single user group would have collapsed very different experiences into one. We would have missed that the blockers at the start of the journey are completely different from those at the end.\n3. Carrying Out the User Interviews\nBefore the first call, make sure you have recording and transcription enabled on your meeting platform. Get approval from the user upfront. This is non-negotiable.\nA plan? Check. Interviews scheduled? Check. Now, this is where you start acquiring data. A bunch of user interviews are lined up for the week; the interesting part is asking questions and listening to your users talk. Because you have a plan set up with your question bank, it makes it easier, but a user may say something you are not expecting, and it is important to ask follow-up questions to dig deeper.\nWe have AI infused into our meeting platform, so recording and transcribing were seamless. Tools like Otter.ai, Fireflies, or even the built-in transcription on Google Meet and Zoom work well here. The transcript becomes your best friend in the next phase. Trust me on that.\n4. The Storm Before the Calm\nPhew. The interviews are done, and it has been quite a week. Twenty calls across three different user groups, and now I am sitting with a folder full of transcripts and recordings staring back at me.\nHere is the thing nobody really tells you about user research. The interviews are actually the fun part. You are in a flow state, asking questions, listening, picking up insights in real time. Post-interview is when the actual work begins. You have raw data and need to analyse it and draw insights.\nI opened the first transcript. Then the second. By the fifth one, I already had contradicting information. A user from group one said the process was straightforward. A user from group two said they had no idea what they were supposed to do at the exact same step. Both were right. They were just at different points in their journey. But reading transcript by transcript, it is genuinely hard to hold it all together.\nI needed a way to find patterns from these conversations without losing the nuance. That is when I turned to thematic analysis.\n5. Introducing Thematic Analysis\nThematic analysis is a way to form patterns from qualitative data. You break down your data into labels called codes, and then group those codes into bigger themes.\nHere is how I approached it. I gathered all the transcripts and read through them, coding and labelling each one. A code is simply a short label that captures what a user is saying or feeling at that point. For example, a user said, "It took me 5 minutes to complete," and the code for that was completion time. Another said, "One thing I like is that delivery is swift", and the code was ‘merchant satisfaction’. Another said, "I don't think anyone should have issues filling the information", and the code was ‘perceived difficulty’.\nDoing this across 20 transcripts, you start to pick up patterns. The same ideas are showing up just in different words. That is your signal.\nNext, group similar codes into themes. Codes like 'completion time', 'perceived difficulty', and 'document readiness' all pointed to the same underlying problem. They became one theme: Activation Friction. \nWhere you have a cluster of related but distinct codes under one theme, those become sub-themes, a way of preserving the detail without losing the bigger picture.\nBy the end, I had 8 themes that cut across all three user groups. What made this powerful was seeing which themes were universal across the journey and which ones were specific to a particular stage.\n6. Where AI Fits In\nNow let's address what everyone is thinking. Reading through twenty transcripts? Three groups? Coding responses manually? This sounds like a lot, and this is where AI can come in to make your work significantly easier.\nOnce I had my transcripts ready, I fed them into an AI tool. ChatGPT works well for this, as does Claude or a dedicated research tool like Dovetail. I prompted it to code responses, identify similar phrases, and flag recurring sentiments. What would have taken me an entire day was done in a fraction of the time.\nHere is something important, though. AI gives you a strong starting point, not a final answer. The interpretation of what those patterns actually mean for your product still sits with you. You handle the thinking.\n7. From Themes to Product Insights\nHaving 8 themes feels good. But themes alone don't ship features. The next step was turning what I found into something the team could actually act on.\nI broke down each theme into four sections in my research report.\nWhat We Heard. This section was a brief summary of what users said about the theme, with sample quotes to support it. For example, under the theme of Activation Friction, quotes clustered around not knowing a document was required, or needing time to gather specific documents before completing the flow.\nWhy It Matters. How does this theme affect the user journey? Does it cause delayed activation? Drop-off? Frustration that only surfaces later? This section connects the theme to a real business or experience consequence.\nWhat It Means. This is where you translate the theme into a product diagnosis. Where does the issue actually come from? Is the form too long, or is it the missing visual cues that tell users what to prepare? Are users benchmarking against a competitor's experience? This section separates the symptom from the cause.\nRecommendations. Based on everything identified, what should the team do? This is where research becomes a roadmap. Before the analysis, conversations with stakeholders were centred on surface-level fixes. After that, we were talking about the right problems.\n8. What Thematic Analysis Changed\nHonestly? It changed how I think about qualitative data altogether.\nThematic analysis gave me a process, and having a process meant I could defend my insights. Walking into stakeholder meetings, the conversation wasn't "users seem frustrated with the journey." It was saying "across all three user groups, activation friction and perceived difficulty were the two most consistent themes, and here is the\nIf you are a product manager sitting on a pile of interview transcripts right now and wondering where to start, start here. The themes are already in your data. Thematic analysis just helps you find them. The messy data was never the problem. It was always the signal.

Turning Messy Data into User Insights: Using Thematic Analysis

Research Presented by Prof Adeolu Afolabi at Moniepoint Research Talks, March 2026\nMoniepoint Research Talks is our monthly engineering chat, where research meets practice. Each month, we host academics and senior engineering experts to share insights that help engineers build better systems, solve real-world problems, and advance their craft.\nIntroduction\nThe world of financial technology changes fast. In 2026, banks and payment apps use smart tools like AI and blockchain to keep money safe. Companies in Nigeria like Moniepoint, Kuda, and Flutterwave lead the way. They help people pay bills and get loans through mobile phones. Since everything is digital, these platforms must be very strong. If a digital platform has even one small hole, thieves can cause big trouble. Security is the most important part of any banking app today.\nWho Uses Fintech?\nTo understand security, we must look at who uses these tools. There are four main groups in the fintech world. Each group needs protection from hackers.\nBanks to Banks:\n This is where large banks use technology to communicate with other banks. It is called business-to-business or B2B.\nClients to Banks:\n This refers to a large company or client working with a bank.\nBusiness-to-Consumer:\n This is when small businesses provide services to consumers.\nConsumer-to-Business:\n This is the most common way regular people use apps to pay for goods and services.\nEach group has different needs. A big bank needs to move millions of dollars safely. A small shop owner just needs to make sure their daily sales do not go missing. Because there are so many users, the risks are always growing.\nModern Cyber Threats in 2026\nThieves have become very smart by 2026. They no longer just guess passwords. They use high-tech tools to trick people. Here are the top threats facing users and banks today.\nAI-Powered Phishing\nPhishing is when a thief sends a fake message to steal your info. In 2026, they use AI to make these messages look perfect. They send texts on WhatsApp or SMS that look exactly like your bank’s official mail. Many people fall for these because they look so real. If a person does not know much about digital tools, they are at high risk.\nDeepfake Voice Fraud\nThieves now use AI to copy voices. They can make a phone call sounding like a bank boss or a family member. They use this fake voice to ask for money or a password. This is why authentication is so important. Banks must check if the person on the phone is actually who they say they are. These attacks happen very fast, making them hard to stop.\nSleeper Account Fraud\nSometimes, people open a bank account and do not use it for months. These are called dormant or sleeper accounts. Criminals look for these quiet accounts. They use them to move stolen money around. It is a big blind spot for many computer systems.\nSIM Swapping and OTP Theft\nYour phone number is a key to your bank. In a SIM swap, a thief takes over your phone number. They then receive your One-Time Password (OTP) on their phone. With the OTP, they can reset your banking password and steal your money. This happens when phone companies have weak security.\nKYC Farming\nKYC stands for "Know Your Customer." Banks use ID cards to verify users. Thieves now use real ID cards to create many fake accounts. These are called mole accounts. They use these accounts to hide their tracks when they commit crimes.\nFinancial Losses and Challenges\nCybercrime costs a lot of money. In Nigeria, the numbers show how much is at stake. Even though we are getting better at stopping it, the attempts are still very high.\nYear\nMoney Lost to Fraud (Naira)\nStatus\n2024\n52.26 Billion\nVery High\n2025\n25.85 Billion\nDecreasing\nThe amount of money lost went down in 2025, but it is a lot. When people lose money, they stop trusting digital banks. This makes it harder for the country to grow its economy.\nRegulatory Problems\nThe Central Bank of Nigeria (CBN) has new rules to stop these crimes. However, there are still many challenges. Sometimes it takes too long to get approval for new security tools. About 62.5% of the time, there are delays in getting site approvals. This slow pace helps the criminals stay ahead.\nCommon Financial Crimes to Watch\nWe must look at how criminals move money. They use several tricks to bypass the rules.\nOnline Money Laundering:\n Criminals use cryptocurrency to hide where their money came from. These funds are often hard for the bank to track.\nFake Loan Creation:\n Thieves use "synthetic identities." This is when they mix real and fake info to create a new person. They use this fake person to take out loans they never pay back.\nPayment Fraud and Chargebacks:\n Some users lie and say they never bought an item. They get their money back, but the business loses out.\nPOS Malware:\n Software that attacks point-of-sale (POS) machines. It steals data when you swipe your card at a store.\nThe Layered Defence Plan\nTo stop these crimes, we need a layered plan. If one layer fails, the next one stops the thief. There are four main layers of security.\nPhysical Security: \nThis protects the actual hardware and buildings. It uses tools like fingerprint scanners to let people in.\nNetwork Security:\n This uses firewalls to block bad traffic. It keeps the internet's "pipes" safe.\nApplication Security:\n This protects the app or software itself. It makes sure the code has no holes.\nData Security:\n This involves encrypting the data. Even if a thief steals the data, they cannot read it without a special key.\nUsing all these layers makes the system hard to break. It creates a safety net for every transaction.\nUsing AI for Better Detection\nOld computer systems use simple rules. For example, a rule might be "stop any payment over $5,000." But thieves know these rules. In 2026, we use Machine Learning (ML) to spot weird behaviour.\nSupervised Learning\nWe train the computer by showing it what fraud looks like. It learns the difference between a good buyer and a thief. We use tools like Decision Trees and Support Vector Machines to label transactions.\nUnsupervised Learning\nThis is even smarter. The computer looks for patterns on its own. It finds "outliers" or strange actions that do not fit the normal routine. It can find new types of fraud that we have never seen before.\nGraph Neural Networks\nThis tool looks at how different accounts are connected. If ten different accounts are all sending money to one person in a strange way, the computer flags it. This helps stop big crime networks.\nBehavioural Biometrics: The Future of Security\nPasswords are not enough anymore. In 2026, we look at who you are and how you act. This is called behavioural biometrics.\nThe system can track:\nHow fast you type on your phone.\nHow much pressure you use on the touch screen.\nThe way you move your computer mouse.\nThe way you hold your phone or walk.\nIf a thief steals your phone and tries to use your app, the system will notice. They do not type like you. They do not hold the phone like you. The app will lock itself instantly. This is a very strong way to stop unauthorised users.\nBetter Security Strategies\nBanks are moving away from old habits. They now use a "Zero Trust" model. This means the system trusts no one. Every single time someone tries to move money, the system checks their ID. It does not matter if they just logged in a minute ago.\nBanks also use Red Teaming. This is when a team of good hackers tries to break into the bank. They find the weak spots before the bad guys do. This helps the bank fix problems early. They also scan their systems every day to find any new bugs.\nThe Human Side of Security\nTechnology is only half of the battle. People are the other half. Even the best AI cannot save a bank if an employee helps a thief. This is called an insider threat.\nTo stay safe, companies must:\nTrain Employees:\n Every worker must know how to spot a fake email.\nReport Early:\n If something looks wrong, workers must say something right away.\nBuild Ethics:\n Workers need to have a strong sense of right and wrong.\nWork Together: \nThe tech and office teams must communicate with each other.\nWhen everyone works together, the whole system becomes much safer.\nConclusion\nCybersecurity in 2026 is a constant battle. As thieves use AI to steal, banks must use AI to protect. A good security plan must have many layers. It needs to use physical locks, smart code, and careful data tracking. By using tools like Zero Trust and behavioural biometrics, we can stop fraud before it starts.\nThe goal is to create a safe place for everyone to use money. Nigeria's fintech world is growing fast. If we keep our systems strong and our people trained, we can build a future where everyone's money is safe. We must stay ready for new threats and keep improving our tools every day.\n
\nAbout the Speaker\nProfessor Adeolu O. Afolabi is a Professor of Information Security and E-Learning in the Department of Cyber Security at Ladoke Akintola University of Technology (LAUTECH).\nHe holds a PhD in Computer Science from Obafemi Awolowo University (OAU) and has built a distinguished career at the intersection of cybersecurity, research, and academia. With over 60 peer-reviewed publications and four textbooks to his name, he is a leading voice in information security research.\nHe is a member of several professional bodies, including the Computer Professionals Registration Council of Nigeria (MCPN), the Nigeria Computer Society (MNCS), and the International Association of Engineers (IAENG), and currently serves on the Governing Council of LAUTECH.\n

How to Protect Fintech Systems from Cyber Attacks in 2026

Many developers face the same nightmare. You launch a service, and suddenly the database is overloaded. This leads to a total system collapse. You might ask yourself how many threads you need or how large your connection pool should be. Most people try to fix this by guessing. They run a load test or scale up slowly and hope for the best.\nThere is a better way to solve these problems. You can use math to predict how your system will behave. This is called Queueing Theory. Everything in computing is a queue. The way your operating system schedules tasks and the way network packets move are all queues. If you understand the math behind these queues, you can build systems that do not crash under pressure.\nWhat Is a Queue?\nA queue is just a line. You see them at the bank or the hospital. In a computer, a queue holds requests waiting for a server. There are three main parts to any queue:\nArrival Rate: This is how fast new requests come in.\nService Time: This is how long it takes the server to finish one request.\nService Rate: This is the number of requests the server can handle per unit time.\nIf you do not plan your queue well, the line will grow too long. Long lines mean slow response times for your customers. If you add too many servers, you waste money and resources. Queueing theory helps you find the perfect balance.\nThe Problem with Independence\nMost math models assume that every request is independent. This means that one person joining the line doesn't affect the next person. In the real world, this isn't always true. Think about a thundering herd. If a service fails, everyone tries to reconnect at the exact same time. The arrival rate spikes because the previous requests failed. Your math needs to account for these bursts.\nKey Parts of a Queue System\nTo model your system, you need to understand its parts. Engineers use something called Kendall's Notation to describe these systems. You might see terms like MM1 or MMC. These are just codes for how things arrive and how many servers you have.\nQueue Discipline: This is how you pick the next item to process. Most systems use "First In, First Out" (FIFO). Sometimes it is better to skip old requests and process new ones first to keep the system moving.\nSystem Capacity: The limit on how many requests can wait. Many businesses want infinite capacity, but that can lead to hidden overloads.\nPopulation Size: The total number of potential customers. For a doctor, it is the number of sick people in town. In a web app, we usually treat this as infinite.\nThe Rule of Utilisation\nThe most important number in queueing theory is utilisation. You calculate this by dividing your arrival rate by your service rate. It tells you how busy your server is.\nYou must keep your utilisation below 100%. If your utilisation hits 1.0, your queue will grow forever. In fact, you should aim for much lower. Once you pass 70% utilization, your system will likely start to struggle.\nThe Hockey Stick Effect\nWhen utilisation stays low, the wait time is short. But as you get closer to 100%, the wait time does not just grow a little bit. It explodes. This is called the hockey stick effect. If your CPU or database is at 90% utilization, a tiny spike in traffic will cause a massive backup. It becomes very hard for the system to recover from this state.\nLittle's Law: The Simple Formula\nYou do not need to be a math genius to use these ideas. A man named John Little created a simple rule called Little's Law. It is an approximation that works for almost any system.\nThe formula helps you find the average number of items in your system. If you know how fast requests arrive and how long they take to process, you can find your queue length.\nAverage Number of Items = Arrival Rate x Average Wait Time\nThis formula is very helpful for tuning your settings. You can use it to figure out how many threads your Tomcat server needs. You can also use it to set the size of your network queue. It hides the complex math and gives you a clear target.\nWhy Variance Matters\nEven if your average speed is good, variance can kill your performance. Variance means that some requests are much slower than others. If one request takes a long time, it blocks everything behind it.\nThis is why you should look beyond the average. You should track these metrics:\nP50 (Median): The middle speed.\nP99: The speed for the slowest 1% of requests.\nYou want your P99 to be as close to your median as possible. If there is a big gap, your system has high variance. High variance makes it much harder to predict when your system will crash.\nPractical Steps for Engineering\nYou can apply these rules to many parts of your tech stack. Here are three common areas where queueing theory helps:\n1. Connection Pools\nDon't just guess your database connection pool size. Treat each connection as a server. If your queries take 10 milliseconds and you get 90 queries per second, you can calculate the exact pool size you need. Aim to keep the pool utilisation under 70%.\n2. Thread Pools\nYour application has a limit on the number of threads it can run. If the thread pool is too small, requests wait too long. If it is too large, the CPU wastes time switching between them. Use Little's Law to find the right number of threads based on your arrival rate.\n3. Fail Fast with Timeouts\nDon't let people wait forever in a queue. This is called an unbounded queue. It hides the fact that your system is overloaded. Instead, set a short timeout. If the queue is full, tell the user to try again later. This is called failing fast. It prevents requests from piling up and crashing your entire network.\nComponent\nWhat it Represents\nGoal\nArrival Rate\nNew user requests\nMeasure and monitor\nService Rate\nDB or CPU speed\nImprove with better code\nUtilization\nSystem load\nKeep under 70%\nK (Capacity)\nQueue limit\nLimit to avoid hidden lag\nConclusion\nQueueing theory is a powerful tool for any developer. It moves you away from guessing and toward making smart decisions. Most production issues arise from a database overload or an incorrect connection pool. By understanding arrival rates and utilisation, you can stop these problems before they start.\nRemember to keep your systems stable. Do not let your utilisation climb too high. Watch your variance and try to keep your slowest requests under control. If you use these mathematical models, you can build services that stay fast and reliable even when traffic spikes. Applying just a little bit of science to your scaling will save you hours of debugging in the future.\n
Ope communicates this in detail in \nthis video\n

How to Use Queueing Theory to Stop Your Database from Crashing

Introduction\nMoniepoint Research Talks is our monthly engineering chat, where research meets practice. Each month, we host academics and senior engineering experts to share insights that help engineers build better systems, solve real-world problems, and advance their craft.\nIn this edition, Professor Babajide Samuel Afolabi from Obafemi Awolowo University reminded us of a time when sending money to a student meant handing cash to a bus driver and waiting 21 days for it to arrive or paying exorbitant fees for postal orders. While fintech has revolutionised speed and access, a significant gap remains: trust and true inclusion.\nAt Moniepoint, we pride ourselves on building reliable infrastructure for businesses. But as Professor Afolabi highlighted in his talk, "User Modelling for Enhanced Fintech Services," technology alone isn't enough. To truly serve the 25% of Nigerian adults who remain unbanked, we must move beyond standard demographics and build digital "mirrors" that reflect real human behaviour. This post summarises the key takeaways from his session, exploring how engineers can use data to bridge the gap between code and customer reality.\nKey Concepts Covered\nUser Modelling:\n Creating digital representations of users based on data and behaviour.\nThe Trust Gap:\n The difference between urban risk-taking and rural reliability.\nPersona Development:\n Moving beyond "users" to specific profiles like "Amina" or "Chinedu".\nBehavioural Forensics:\n Using metadata (like MAC addresses) to detect fraud.\nWhat is User Modelling?\nProfessor Afolabi defines user modelling as "building a mirror that helps us to see our users more clearly". It is not just about logging transactions; it is about creating a dynamic profile that helps in personalisation, prediction, and segmentation.\nFor engineers, this means shifting focus from what a user does (clicks, transfers) to who the user is.\nUrban Users:\n Prioritise speed and instant delivery. They are risk-takers but lack loyalty (trust is not in their vocabulary).\nRural Users:\n Prioritise safety and reliability. They are sceptical, but once you earn their trust, they remain loyal indefinitely.\nWhy It Matters: The "Egg" Analogy\nProfessor Afolabi shared a powerful story about financial literacy. A woman was given capital to start a small business selling bread and eggs. On her first day, she became hungry, boiled six eggs, and ate a loaf of bread, consuming her capital before making a sale.\nThe Engineering Takeaway: We cannot simply "throw technology" at this problem. If a user doesn't understand that capital isn't revenue, a complex dashboard won't help them. We must design interfaces that guide behaviour, perhaps using voice prompts for the illiterate or simplified "safe-to-spend" balances.\n3 Steps to Implementing User Modelling\nBased on the talk, here is a framework for implementing better user models in our stack.\nStep 1: Data Audit and Segmentation\nWe must look beyond standard transaction logs. Useful data sources include:\nTransaction frequency:\n Does the user withdraw immediately after receiving funds?\nDevice usage:\n Are they on a smartphone or a feature phone?\nExternal data:\n Regulatory data and customer support interactions.\nAction:\n Audit your current data pipelines. Are you capturing the "silence" from users who aren't providing feedback?\nStep 2: Develop Detailed Personas\nDon't design for "everyone." Design for specific archetypes. Professor Afolabi outlined three key personas relevant to our market:\nAmina (The Rural Trader):\n Uses POS for daily sales, may have low literacy, needs voice prompts.\nChinedu (The Urban Student):\n Tech-savvy, seeks microloans, price-sensitive.\nNgozi (The MSME Owner):\n Needs payroll management and staff oversight tools.\nStep 3: Predictive Modelling for Fraud\nBehavioural modelling is our best defence against fraud.\nThe Case Study:\n During a university exam, tracking shifted from IP addresses to MAC addresses. The team discovered that 100 students had submitted exams from the same device within 7 hours, exposing an AI-cheating ring.\nApplication:\n In fintech, we can flag accounts when behavioural patterns (such as device usage or location) suddenly shift, helping catch fraud before it occurs.\nA Mirror on Moniepoint: Strengths and Weaknesses\nOne of the most valuable parts of the session was Professor Afolabi’s candid assessment of Moniepoint’s current market standing.\nWhat We Are Doing Right\nMSME Focus:\n We are correctly identified as the champion of the informal sector, including bread sellers and grocery owners.\nReliability:\n Our POS terminals are often called "personal ATMs" because they continue to work when traditional bank networks fail.\nSimplicity:\n Users appreciate that our tools "just work" without unnecessary flashy features.\nAreas for Improvement\nCustomer Support:\n There is a perception of delayed responses. For a rural user, a delayed resolution immediately erodes trust.\nDispute Resolution:\n Handling failed transactions and "hanging" funds remains a critical pain point.\nUser Feedback Loops:\n We need to listen to what users are doing (e.g., uninstalling the app) as much as what they say on social media.\nTroubleshooting & Discussion\nDuring the session, several key questions arose regarding how we apply these theories.\nQuestion:\n How do we reach the unbanked who don't trust banks?\nAnswer:\n Leverage the device they already trust: their phone. As of 2025, mobile penetration in Nigeria is at 87%, higher than the banked population. Solutions like M-Pesa succeeded by starting with basic USSD text services rather than complex apps.\nQuestion:\n How can we improve UX for low-literacy users? \nAnswer:\n Move beyond text. Research found that "Amina" (the rural trader persona) could easily navigate tricky interfaces when voice prompts were added.\nQuestion:\n Is technology always the solution? \nAnswer:\n No. Sometimes a user stops using an app simply because they don't understand the loan terms, not because the app is buggy. This is a communication gap, not a code bug.\nConclusion\nProfessor Afolabi left us with a striking calculation: If we capture 40 million users and earn just ₦100 per user per day, the revenue impact would be massive but only if we retain their trust.\nUser modelling is not just an academic exercise; it is the path to financial inclusion. By understanding the "Amina" in Wasimi and the "Chinedu" in Lagos, we can build products that are not just functional but essential. As we continue to refine our engineering roadmap, let’s remember: "Listen to the customer... Listen to what they are saying and what they are not saying".\nYou can watch the session \nhere\n

Data Connections For Fintech Services

Moniepoint Research Talks is our monthly engineering chat, where research meets practice. Each month, we host academics and senior engineering experts to share insights that help engineers build better systems, solve real-world problems, and advance their craft.\nIn this edition, Dr Oladipupo Sennaike from the Department of Computer Sciences at the University of Lagos (UNILAG), for a recent instalment of the Moniepoint Research Talks. Dr Sennaike presented his research on automatically discovering connections within vast collections of public data, demonstrating a robust method for improving how we interact with open data globally.\nThe Context: Why Open Data Portals Matter\nOpen data portals are online platforms that provide access to collections of open, freely available data intended for reuse. Globally, there are over 2,600 such portals, including major examples such as data.gov for the U.S. government and data.gov.uk for the U.K., as well as the Nigeria Data Portal and the World Bank Open Data platform.\nThese portals are critical for several reasons:\nTransparency & Accountability:\n They enable citizens to access information on government spending, budgets, and public projects.    Cxxzxxz z\nInnovation & Entrepreneurship:\n Developers and startups leverage open data to build new fintech, transport, health, and civic-tech products.\nResearch & Education:\n Academics and analysts use these datasets for modelling, policy research, and AI training. Furthermore, data collected from these portals provides the evidence needed to ensure that policies are based on real-world evidence.\nBetter Public Services:\n Governments can improve planning for sectors like transport, health, and agriculture by harnessing insights derived from this data.\nOpen Data Portals generally operate on a generic three-layer architecture: the \nUser Interface \n(containing the Catalogue UI, Search UI, Analytics, and APIs), \nServices \n(handling the data catalogue, metadata management, and search), and \nStorage \n(managing files, structured data, and indices).
⁠\n\n
⁠The Core Problem: Current Limitations in Search\nDespite their importance, existing open data platforms offer only basic search capabilities and simple filtering. A critical limitation is the \nlack of recommendations for related datasets\n. Understanding which datasets are related (or semantically connected) is essential for users who want to integrate or "mash-up" data for comprehensive analysis or to create new data-driven services.\nGiven the scale of these catalogues data.gov, for example, hosts over 350,000 datasets, and data.gov.uk has over 55,000, manually specifying the relatedness relationships across them is simply infeasible.\nThe Research Objective: Automating Semantic Relatedness\nDr. Sennaike’s primary goal was to determine the \nimplicit semantic relatedness\n of datasets published within a catalogue. The proposed solution was to use a Self-Organising Map (SOM) to generate automated dataset recommendations during search operations.\nThe work acknowledged other established methods for measuring relatedness, such as Lexical resource-based approaches, Explicit Semantic Analysis (ESA), and Latent Dirichlet Allocation (LDA) for topic modelling. Still, it focused on the SOM's unsupervised capabilities.\nLeveraging Kohonen’s Self-Organising Maps (SOM)\nA \nSelf-Organising Map (SOM)\n is a type of unsupervised artificial neural network. Unlike supervised learning, where a model is trained on labelled data (and its accuracy is easily measured by comparing its output to the correct label), unsupervised learning can learn connections from unlabeled data. The SOM acts similarly to clustering algorithms by grouping similar concepts, but its clusters do not have hard boundaries.\nThe core functionality of the SOM algorithm is dimensional reduction: it projects high-dimensional input data (with many attributes or features) onto a low-dimensional space, typically a two-dimensional map, while preserving \ntopological order\n. This preservation means that \nrelated data points are placed close to one another on the resulting map\n.\nThe SOM consists of nodes or units arranged in a regular rectangular or hexagonal grid. Each node is associated with an n-dimensional \nmodel vector\n (or weights) that approximates the set of input data, where \nn\n is the dimension of the input space (the number of features).\nDuring training, data items are presented to the nodes in parallel. The nodes compete, and the node with the \nbest-matching model vector, usually determined by\n the Euclidean distance metric, emerges as the winner. The model vectors (weights) of this winning unit and its neighbours are then adjusted (or strengthened) to move closer to the input data, enabling learning. This adjustment to the surrounding nodes is critical, as it defines the neighbourhood size and helps preserve the topological order.\n\n
⁠\nThe SOM Model Development Process\nThe research utilised a five-step methodology to implement the SOM-based recommendation engine:
⁠\n\n
⁠\n1. Data Preparation and Extraction\nThe study focused on 255 open datasets from the \nDublin City Open Data Platform (DubLinked)\n. This catalogue includes diverse information ranging from pedestrian footfall indices to commercial lease registrars and sculptures in public parks.\nData was extracted from the DubLinked CKAN platform instance using its \nREST API\n. The extraction captured essential metadata, including the dataset's \nTitle\n, \nOrganisation\n, \nTheme\n, and \nTags\n. Furthermore, \nNamed Entity Recognition (NER)\n was employed to extract specific entities, such as people, organisations, and locations, from the content and metadata, thereby enriching the dataset description.\n[TABLE: Extracted Dataset Features, including Title, Organization, Theme, Notes, Tag, Resource Fields, Location, Person, and Organization]\n2. Data Transformation\nSince the SOM requires numeric vector input, the text-based metadata and features were transformed into a \nDocument Term matrix\n using the Term Frequency–Inverse Document Frequency (\ntf-idf\n) metrics. This common NLP technique converts variable-length text documents into a fixed-size numeric representation, ensuring regularity across all datasets. The resulting input matrix for the SOM was 255 by 1241 (representing the 255 datasets and 1,241 terms/features extracted).\n3. Model Selection, Validation, and Results\nSince there was no labelled data to rely on, the researchers experimented with different map sizes to find the optimal SOM configuration. Selection was based on two key metrics:\nTopological Error:\n This measures the proportion of input samples in which the first- and second-best matching units are \nnot\n neighbours on the map. A low error suggests that topologically close items on the map are genuinely similar in the source data.\nQuantisation Error: \nThis is the average distance between the input data and the model vector of its best-matching unit. This indicates how accurately the map represents the overall training data.
\n\nFor validation, the process relied on \ndomain experts\n who examined the categories discovered by the map. A category was defined by the data items falling onto a specific node, plus those within a specified radius around that node. Across all testing cases, these experts successfully inferred the underlying concept addressed by each map category, even when the neighbourhood radius was increased.\nThe resulting SOM visualisations revealed clear groupings of semantically related datasets:\n\n\n
⁠\n\n
⁠Further analysis using \nWord Clouds \nbased on the metadata and node features helped visualise the concepts captured by clusters of datasets. For example, one node might clearly display keywords such as Culture, Heritage, and Arts, confirming that the topic is being grouped.
⁠
⁠\n\n
⁠\nApplication and Conclusion\nThe developed SOM-based model effectively computed semantic relatedness among datasets, providing strong evidence for the efficacy of the unsupervised approach. This method reveals opportunities for innovation implicit in the data catalogue by making hidden connections explicit.\nWhen incorporated into a search interface, the model generated highly relevant recommendations:\nA user searching for the "\nLuas Stops\n" dataset (Dublin’s tram network) received related resources like "\nTraffic Volumes\n," "\nReal-time passenger Information (RTPI) for Dublin Bus\n," and "\nCommercial Bus Services in Ireland\n".\nA search for the "\nParks\n" dataset yielded connections to "\nArt in the Parks\n," "\nDLR Landscape Maintenance\n," and "\nTrees\n".\n\n
⁠\nChallenges and Future Work\nWhile the SOM approach proved robust, the research identified ongoing challenges. Specifically, poor-quality metadata and data could negatively affect the model's effectiveness, as it relies heavily on textual descriptions and entity recognition extracted from this metadata.\nFuture work will focus on integrating the model with other tools to enable the seamless integration of compatible datasets and applying the model to much larger-scale data catalogues beyond the initial 255 used in this study.

Discovering connections in open datasets

Introduction\nMoniepoint Research Talks is our monthly engineering chat, where research meets practice. Each month, we host academics and senior engineering experts to share insights that help engineers build better systems, solve real-world problems, and advance their craft.\nIn this edition, \nDr\n \nIshaya Gambo\n, a leading researcher from \nObafemi Awolowo\n University, shared his research on "Redefining Stakeholder Engagement in Software Engineering”. His insights forged through years of research, including during his master's and PhD, focused on resolving conflicts among software development stakeholders, challenging our conventional views on development and requirements gathering.\nAt the heart of Dr Gambo’s message is a fundamental truth: \nEvery successful system runs on two APIs: the machine API and the human API\n. While technical APIs define how systems communicate, \nHuman APIs define how people understand each other\n. When the Human API breaks, even if the code is perfectly clean, the project is destined to fail.\nThis is why, at Moniepoint, we are moving beyond passive requirement collection towards a model of continuous relationship-building, treating requirements as living conversations.\n\n\n
⁠\n
⁠The Challenge We Face in Fintech\nMoniepoint operates within a highly intricate ecosystem. Every product decision impacts a diverse array of influential stakeholders. This complexity often leads to conflicting demands when launching a new feature, such as a payment service:\nThe Business Team:\n Often wants speed and revenue generation, expressing the need for the product "yesterday".\nThe Customers (Individuals & SMEs):\n Demand simplicity, ease of use, reliability, and unwavering trust.\nThe Compliance Team:\n Is primarily interested in security and ensuring regulatory rules (like those set by the CBN) are not compromised.\nThe Developers/Engineers:\n Need a clear set of requirements to deliver the system successfully.\nIn this competitive fintech landscape, where \ntrust is the primary currency\n, poor stakeholder engagement directly leads to project delays, costly rework, and lower user satisfaction.\n
⁠Moving Beyond the Traditional Approach\nThe traditional software development model often follows a rigid, linear path: \nGather Requirements -> Build -> Deploy\n. Dr. Gambo highlighted that this waterfall-like rigidity inevitably leads to crises:\n
⁠The Gaps of Traditional Software Development\nThe critical element missing from the conventional approach is \ncontinuous relationship building\n. This absence creates three major problems:\nConflicting Requirements:\n Requirements gathered from different stakeholders frequently conflict, leading to reactive compromises late in the process.\nLate-Stage Changes:\n Development is often disrupted when stakeholders realise midway through the project that the solution doesn't align with their true vision, leading to scope creep and delays.\nStakeholder Dissatisfaction:\n Even when the final product technically meets the documented requirements, stakeholders remain unhappy because we addressed their \nstated wants\n instead of their \nunderlying needs\n.\n
⁠A New Perspective: Requirements as Conversations\nTo overcome these gaps, \nDr. Gambo\n proposes a new perspective rooted in research, viewing requirements as ongoing conversations built on deeper inquiry and trust:\n
⁠1. From Collecting to Engaging\nWe must shift from passively collecting requirements as static artefacts to actively \nengaging\n with stakeholders to discover needs through collaborative exploration. This involves proactive interaction, such as engineers sourcing feedback directly from Moniepoint customers or holding cross-functional brainstorming sessions.\n
⁠2. From Static Documents to Ongoing Dialogue\nA requirement must not be treated as a document to be signed off or frozen. Instead, we must treat it as a \nliving conversation\n that evolves as our collective understanding of the problem deepens and new insights arrive.\n
⁠3. From ‘What’ to ‘Why’\nThe focus of our inquiry must move beyond \nwhat\n the stakeholder wants (e.g., "faster payment process") to \nwhy\n they want it. Unveiling the 'why' reveals the true underlying business or user problem, which is crucial because a requirement defined by one stakeholder might mean something entirely different to another.\n
⁠4. From Transaction to Trust\nThe ultimate goal of stakeholder engagement should be the \ncultivation of trust\n, rather than a simple transactional exchange of information. This trust makes all subsequent collaboration, innovation, and relationship management more efficient and effective.\n
⁠The Three-Pillar Framework for Better Engagement\nDr. Gambo presented an evidence-based framework for managing the natural conflicts that arise around competing objectives like \nSecurity, Speed, and User Experience (UX)\n. The solution lies not in avoiding conflict, but in how we handle it. The framework consists of three pillars:\n
⁠Pillar 1: Identify\nWe must accurately determine who all the stakeholders are and what they truly need. This means going beyond job titles to understand their roles and motivations.\nAction:\n Employ \nStructured Interviews\n, \nGoal Mapping\n, and \nPersona Development\n.\nKey Distinction:\n Identify both \nfunctional requirements\n (what the system should \ndo\n, e.g., logging in) and the more challenging \nnon-functional requirements\n (what the system should \nbe\n, e.g., fast, secure, usable).\n
⁠Pillar 2: Prioritise\nNot all requirements are equal. We must use a structured approach to choose which requirements deliver the most value.\nCriteria:\n Prioritise based on \nBusiness Value, User Impact, Technical Feasibility,\n and \nCompliance\n.\nResearch Strategy:\n An effective prioritisation strategy, such as the MEO model (Mandatory, Essential, Optional), helps determine which features must be implemented immediately, which are secondary, and which can wait for subsequent releases.\nMethods:\n Practical prioritisation methods include \nWeighted Scoring\n (assigning weights to strategic factors) and \nCollaborative Ranking\n (facilitated sessions in which stakeholders discuss trade-offs). Hybrid models combine quantitative data with qualitative discussion.\n
⁠Pillar 3: Resolve\nWhen stakeholders disagree, the focus must be on \nstructured dialogue, not debate\n.\nTechniques:\n Approaches include \nFacilitated Workshops\n (using a neutral facilitator), \nTransparent Decision Criteria\n (agreeing on criteria before debate starts), and \nTrade-off Analysis\n.\nThe Goal:\n The aim is informed compromise, or \nGoal Consensus\n, where all stakeholders understand the decision, feel their input was valued, and commit to the path forward, not simply creating "winners and losers".\n
⁠Practical Takeaways for Moniepoint\nTo embed this research-driven mindset across our engineering teams, Dr. Gambo provided specific, actionable advice:\nInvest Time in Stakeholder Mapping:\n Know the ecosystem intimately, including regulators, customers, merchants, and internal teams, to understand their diverse needs and perspectives.\nCreate Regular Touchpoints:\n Establish frequent points of engagement (e.g., monthly or bi-annual field work) with key stakeholder groups, such as Moniepoint customers or POS individuals, to gather deep insights and information that were previously unconsidered.\nUse Structured Methods for Prioritisation:\n Avoid relying solely on intuition; use structured, research-backed methods to prioritise requirements and manage resources effectively.\nAddress Conflicts Early:\n Utilise facilitated conversations to resolve conflicts proactively.\nDocument Decisions and Rationales Transparently:\n Ensure all decisions and their justifications are clear and accessible to build trust.\n
⁠Building a Culture of Engagement\nUltimately, Moniepoint's engineering future is human-centred. This shift is not merely about implementing new processes; \nit is about building a mindset\n.\nA culture of engagement means recognising that the product, process, and \npeople\n are the three key pillars of software engineering. We must foster an environment that:\nEncourages cross-functional collaboration.\nCreates safe spaces for voicing concerns, where every perspective is valued.\nCelebrates stakeholder partnerships and learns from every project.\nBy investing in relationships, we see measurable business impacts, including \nFaster Time-to-Market\n, \nReduced Project Risks\n (since conflicts are addressed early), and \nHigher User Satisfaction\n (because true needs are met).\nAt Moniepoint, every feature we build connects a network of stakeholders, and these relationships are our true architecture. When we embed empathy and evidence-based engagement in engineering, we don't just build systems, \nwe build significance.

From Requirements to Relationships: How Moniepoint Engineers are Redefining Stakeholder Engagement

\n\n
Introduction\nMoniepoint Research Talks is our monthly engineering chat, where research meets practice. Each month, we host academics and senior engineering experts to share insights that help engineers build better systems, solve real-world problems, and advance their craft.\nIn this edition, we welcomed Dr Victor Odumuyiwa, Research Lead at the Machine Intelligence Research Group at UNILAG. In his presentation, he explored how transformer models are applied to financial texts to uncover customer insights.\nThe fundamental challenge in leveraging machine intelligence is semantics. How do we ensure machines understand not just the text, but the context surrounding that information? A vast array of possibilities opens up if a machine can truly understand human communication.\nFor organisations dealing with high volumes of customer interactions, this context is crucial. Natural Language Processing (NLP), a subfield of Artificial Intelligence (AI), focuses on programming computers to process and analyse human language data. This guide will detail how Transformer models, the current state-of-the-art in NLP, can be applied to financial texts to automatically generate actionable insights.\n
⁠Prerequisites / What You'll Need\nFamiliarity with foundational AI/ML concepts (RNN, LSTM, Neural Networks).\nBasic understanding of NLP tasks (Classification, Translation, Generation).\nKnowledge of metrics used for model performance evaluation (Precision, Recall/Sensitivity, Accuracy).\n
⁠The Foundation: The Rise of the Transformer Architecture\nThe journey toward contextual understanding evolved through several stages: starting with Recurrent Neural Networks (RNN), moving to Long Short-Term Memory (LSTM), and culminating in the \nTransformer\n architecture.
\nA key limitation of earlier models like LSTM was the difficulty in maintaining context over long sequences (the vanishing gradient problem), even with improvements like Bi-LSTM (processing in both directions).\n\nThe breakthrough came in 2017 when Google published the paper, \n"Attention is all you need"\n. Attention mechanisms changed the flow of NLP by enabling the model to remember and connect words to past words, understanding relationships across the entire sequence, which is critical for human language comprehension.\n
⁠Core Components of the Transformer\nThe Transformer relies on several mechanisms to capture semantic meaning and positional context:\nTokenisation and Embedding:\n Input text is broken down into numerical tokens (words or subwords), which are then converted into numerical vectors (embeddings) to capture their semantic meaning.\nPositional Encoding:\n Since the model processes input in parallel, vectors are added to the input embeddings to provide information about each token's position, ensuring the model understands the order of the sequence.\nSelf-Attention Mechanism:\n This is the core component that determines the relationship between all tokens in a sequence simultaneously, using three vectors for each token:\nQuery (Q): Represents the current token being processed.\nKey (K): Acts as a label for every other token in the sequence.\nValue (V): Contains the actual content of the tokens. By computing attention scores between the Query and all Keys, the model learns how much attention to pay to each Value, forming a weighted, contextual representation.\nBERT (Bidirectional Encoder Representations from Transformers):\n Introduced in 2018, \nBERT\n further refined this by processing text in more directions, leading to better contextual representations. This model started the trend of predicting the next word using masked input, enabling effective content generation.\n
⁠Key NLP Tasks in Financial Services\nThese advanced models are applied across several critical NLP tasks, moving far beyond simple text processing to semantic understanding.\n
⁠Sentiment Analysis (Customer Opinion)\nSentiment analysis determines the opinion expressed in a piece of text (e.g., positive, negative, neutral, angry, or hateful). This is essential for understanding customer intimacy and public perception, especially regarding new products or services.
\nIn testing various models on financial datasets (including customer complaints and financial news), \nBERT\n consistently showed better \nAccuracy, Precision\n, and \nRecall\n results compared to traditional machine learning models like SVM (using TF-IDF) and older neural networks like LSTM. For example, on one financial sentiment analysis dataset (Dataset 2), BERT achieved 83% accuracy, significantly outperforming SVM (68%) and LSTM (70%).\n
⁠Financial Named Entity Recognition (NER)\nNER automatically identifies a document's names and specific entities (like countries, people, or organisations). This capability is critical for relationship extraction and synthesising information from millions of business news articles and documents, giving financial professionals a concise summary and insight.\n\nNER models, using optimisers like AdamW and loss functions like Cross-Entropy, can accurately tag specific entities in sentences, whether using BERT or Llama models.\n
⁠Machine Translation\nSignificant progress has made machine translation highly effective today, unlike the difficulties encountered years ago. Systems leveraging Transformer architectures (like Google's and OpenAI's models) can now translate complex financial documents, such as news concerning an $800 million World Bank grant to the Nigerian government, moving beyond literal translations to retain the general literary meaning.\n
⁠Financial Question Answering (QA)\nFinancial QA involves training a model on specific data, such as company financial reports (10-K filings). The trained machine can then accurately respond to particular questions, reducing the need for humans to handle routine queries. Models like \nRoBERTa\n have been trained to answer questions regarding financial details, such as the value of a one-time transaction tax.\n
⁠Generating Actionable Customer Insights\nThe true value of these NLP tasks lies in combining them to generate comprehensive customer insights, rather than treating them as scattered tasks.\nA system can take unstructured data (like a customer complaint), perform several tasks such as \ncategory detection\n (e.g., Debt collection), \npriority detection\n (e.g., Urgent), and \nsentiment detection\n (e.g., neutral) and then plug this classified information into an LLM or Transformer to generate detailed summaries.\nExample Insight Generation from a Customer Complaint: Based on a complaint detailing an unrecognised debt, an unauthorised account levy, and communication failures due to an outdated address, the combined system generates multi-faceted insights:\nDisputed Debt Handling Issues:\n The required process (affidavit of fraud, police report) was overly burdensome, leading to unresolved disputes.\nCommunication and Notification Failures:\n Legal correspondence was sent to an outdated address, despite the company having the correct, current address on file from a recent payment.\nData Management Concerns:\n This situation reveals a clear breakdown in maintaining and cross-referencing up-to-date customer information, suggesting poor data management.\nCustomer Impact:\n The resulting judgment caused a financial loss ($830 levied) and significant emotional distress for the customer.\nFinally, the system suggests \nProcess Improvement Opportunities\n and \nActionable Insights\n, such as implementing robust address verification protocols before legal actions and simplifying the debt dispute process.\n
⁠Troubleshooting & FAQ\nQuestion:\n When is it most efficient to fine-tune an LLM versus prompt engineering?\nAnswer:\n Fine-tuning and prompt engineering serve different goals, but both depend heavily on the context.\nFine-tuning\n is primarily used to adapt a general model (pre-trained on broad language) to a \nspecific domain\n or form (e.g., financial jargon, JSON output format). You are modifying the model’s parameters to understand your particular data better. For fine-tuning to be effective, you need a substantial dataset—hundreds of thousands of examples, as smaller datasets may yield inaccurate results.\nPrompt Engineering\n (or prompt tuning) helps provide specific \nfacts\n or dictate behaviour, but the size of the context window limits it. If your context is extremely large (e.g., many data sources), prompt tuning may not be viable due to token limits.
\nQuestion:\n For Financial Question Answering, should we use Retrieval-Augmented Generation (RAG) or train from scratch?\nAnswer:\n While you can train a small language model entirely from scratch if you have sufficient data and compute power, RAG is generally recommended for integrating real-time or proprietary financial data.\n
\nRAG augments the knowledge of a pre-trained model (which is limited by the information available during its training, perhaps six months ago) by fetching current, external, or private information. This is necessary to integrate new data into the model’s knowledge base without retraining the expensive base model every day. RAG also provides a mechanism to allow an LLM to interact with sensitive resources, like your internal database, by creating a system that extracts context-specific information for generation, while keeping the database secure.\n
⁠Conclusion: The Road Ahead for African AI\nTransformer models provide unprecedented power for extracting insight from text. However, the future of AI in regions like Africa requires a focus on AI localism.
\nSince most African languages are spoken rather than written, focusing on multimodal data (spoken and acoustic data) is essential to drive financial inclusion. Currently, most African languages (like Yorùbá, Igbo, and Hausa) are poorly represented in global AI tools due to factors like the absence of standardised orthographies and the paucity or absence of digital corpora (web-scale data).\n\nTo maximise the benefits of AI for African populations, there must be intentionality and strong collaboration between industry, academia, and philanthropy. The strategic direction should focus on building and using Small Language Models (SLMs) tailored to local contexts, rather than trying to compete in the race for Artificial General Intelligence (AGI). This focus will ensure that ordinary people, such as small business owners, can benefit from AI by receiving truly contextual and relevant advice.\n

Unlocking Customer Insight: Applying Transformer Models to Unstructured Financial Text

\n\n
Introduction\nMoniepoint Research Talks is our monthly engineering chat, where research meets practice. Each month, we host academics and senior engineering experts to share insights that help engineers build better systems, solve real-world problems, and advance their craft.\nIn this edition, Comfort Lawal from Covenant University shared her research on the use of federated graph neural networks to detect anomalies in the protected systems. \nAccording to her, complexity is the new normal. Enterprises rely on multi-cloud architectures (used by 73% of organisations) that generate an astounding 500+ billion logs daily. This massive, distributed infrastructure poses a severe challenge to security and reliability, especially given that the global annual cost of cybercrime has reached €1.75 trillion. Detecting critical system failures or malicious activity requires an immediate response, often less than 1 second.
⁠\nTraditional anomaly detection methods, such as centralised monitoring and isolated rule-based systems, fail to meet this challenge. They often suffer from privacy violations, bandwidth bottlenecks, high false positive rates, and an inability to adapt to new threats.\n
⁠The Problem with Traditional Approaches\nTraditional security and monitoring methods fall short in these distributed, high-volume environments.\nCentralised Monitoring:\n Fails due to privacy violations when raw data is pooled, creating single points of failure and causing bandwidth bottlenecks.\nIsolated Detection (Classical ML):\n Treats data as independent, leading to high false positive rates. For instance, a poor network connection might be falsely flagged as an anomaly because the system fails to check the related data context.\nRule-Based Systems:\n Cannot adapt to new or evolving threats and require constant, manual maintenance.\n\nThe Solution:\n Converging Technologies\nThe Federated Graph Neural Network (F-GNN) framework is an innovation designed to overcome these critical limitations by combining three powerful technologies:\nGraph Neural Networks (GNNs):\n Capture complex relationships in vast network data, which is a natural fit for cloud systems.\nFederated Learning (FL):\n Allows models to be trained without sharing raw, sensitive data, enabling privacy-preserving collaboration across distributed sites.\nHyperbolic Geometry (HGNN):\n Provides an efficient way to model the hierarchical nature of cloud architectures.\n
⁠Prerequisites / What You'll Need\nDeploying and experimenting with F-GNNs requires expertise and infrastructure across several domains:\nExpertise:\nMachine Learning Engineers with GNN expertise.\nSecurity Engineers experienced in privacy protocols.\nDevOps Engineers for infrastructure management.\nCore Frameworks:\nFlower: Recommended framework for Federated Learning.\nPyTorch Geometric (pyg.org): Used for GNN implementation.\nDGL (dgl.ai): Crucial for distributed graph processing, especially when dealing with large graphs (e.g., 66,000+ nodes and millions of edges).\n
⁠Core Concepts and Technical Deep Dive\nFoundational Concepts:\n Understanding the Building Blocks\nGraph Neural Networks (GNNs)\nCloud systems are a natural fit for graph representation. In this context:\nNodes represent components like Servers, VMs, or Containers.\nEdges represent relationships such as Network connections, Dependencies, or API Calls.\nFeatures include metrics, logs, and system states.\nThe key advantage of GNNs is Message Passing, where nodes learn from their neighbourhood to reduce false positive rates and solve the challenge of isolated detection by considering underlying relationships.\n
⁠Common GNN architectures include:\nGraph Convolutional Networks (GCN):\n Fast and efficient, suitable for static graphs, but perform transductive learning, requiring retraining for new data.\nGraph Attention Networks (GAT):\n Uses an attention mechanism for dynamic importance, often used for threat detection, but it is of higher complexity.\nGraphSAGE:\n Supports inductive learning through scalable sampling, making it suitable for large and constantly changing networks.\n
⁠The Hyperbolic Advantage\nWhen dealing with deeply hierarchical data—such as the structure of a cloud environment (Data centre → Cluster → Node hierarchies)—Euclidean space introduces problems like poor hierarchy preservation and high dimensions. Hyperbolic Geometry naturally caters to these hierarchies, offering:\nNatural hierarchy embedding.\nEfficiency: Requiring 10x fewer parameters.\nPerformance Gain: Demonstrated 16-63% performance gains in the literature.\n
⁠Federated Learning (FL)\nFL allows the training of a Global Model continuously improved by training on decentralised, local graph data residing on different cloud sites that form a federation. This process involves:\nTraining models without sharing raw data.\nEnsuring privacy-preserving collaboration.\n
⁠The Innovation: The Federated GNN Architecture\nThe F-GNN framework operates via a continuous learning cycle coordinated across a decentralised network.
\n1. Local GNN Training\nEach participating cloud centre or edge server trains a GNN model locally using its site-specific data and logs. This layer ensures that raw data privacy is preserved. The local GNN calculates an anomaly score for each node.
⁠\n2. Secure Aggregation\nAfter local training, only the model updates (gradients) are sent to the global coordination server, not the raw data. These updates are protected using advanced privacy techniques:\nPrivacy Technique\nFunction/Guarantee\nDifferential Privacy\nAdds noise injection to the model updates to mask specific information, providing mathematical privacy guarantees\nHomomorphic Encryption\nAllows computation on encrypted data (full privacy) and can involve quantum-resistant options\nSecure Aggregation\nUses secret sharing protocols and Byzantine fault tolerance to protect the combined model updates\nCrucially, implementing security involves a performance vs. privacy trade-off. Testing showed that while full encryption (Homomorphic Encryption) achieved high privacy, accuracy dropped to 85%. Using Differential Privacy (medium privacy) yielded an accuracy of approximately 97%.
\n3. Global Model Distribution\nThe model updates are securely aggregated (often using the FedAvg algorithm with enhancements like gradient clipping) to create an improved global model. This global model is then distributed back to all local sites, completing the continuous learning cycle. The global coordination server can sit in any one of the federating cloud providers.\nMulti-Layer Privacy Protection\nTo secure the model updates transmitted between local clients and the global server, the framework employs multi-layer protection techniques:\nDifferential Privacy (DP):\n Provides mathematical privacy guarantees by adding noise injection to the model updates, masking the information.\nHomomorphic Encryption (HE):\n Allows computation on encrypted data, offering full privacy and quantum-resistant options, although it can significantly impact model accuracy.\nSecure Aggregation:\n Uses secret sharing protocols and Byzantine fault tolerance to ensure secure computation on the updates.\nPerformance Breakthroughs\nImplementing these security measures must not negate the necessity for real-time response. The FGNN framework achieves groundbreaking efficiency through several optimisation techniques:\nCommunication Optimisation:\n The system employs Asynchronous Updates (where clouds send updates based on customised rules, like volume or accuracy changes), Top-k sparsification, and Gradient compression. This optimisation, achieved through methods like FEDZIP, resulted in a 97.6% bandwidth reduction. Communication time dropped from 700 seconds per round to 16.8 seconds per round.\nModel Compression:\n Techniques like Quantisation (reducing updates from 32-bit to 8-bit without information loss), Pruning (removing unnecessary parameters, achieving 50% removal), and Knowledge Distillation (where a faster student model learns from a robust teacher model) provide a 10x speedup and ensure production readiness.\n\nReal-World Impact: Results That Matter\nThe FGNN framework provides high Privacy+Performance.\nMetric\nRange/Value\nInsight\nDetection Rate\n85.02% - 99.998%\nAccuracy for DoS attacks is near-perfect (99.998%).\nLatency\n< 100ms\nEnables true real-time critical alerts.\nCommunication Reduction\n97.6%\nBreakthrough in bandwidth optimisation.\nEnergy Preservation\n99%\nSignificant efficiency gains.\nPrivacy Cost\n12% loss in accuracy\nFull encryption (High Privacy) reduces accuracy from 99.6% (No Protection) to 87.85%.\n\nKey deployment sectors include:\nFinancial Services:\n Used for cross-institution fraud detection, maintaining 99.2% accuracy with zero data breaches.\nCloud Providers:\n Applicable for cost anomaly detection (AWS), cognitive service integration (Azure), and edge deployment readiness (GCP).\nHealthcare:\n Enables distributed patient monitoring and HIPAA-compliant, cross-hospital learning.\nTroubleshooting & FAQ\nQuestion:\n Traditional models often suffer from poor explainability. How does this deep learning approach provide sufficient justification for an anomaly?\nAnswer:\n Explainability is primarily achieved through hierarchical classification, which goes far beyond a simple "anomaly/not anomaly" output. The system breaks down the alert into different levels:\nDetection: An anomaly occurred.\nType of Anomaly: Is it a critical anomaly (system about to fail), an error anomaly, or a warning anomaly (requires different actions)?\nApplication: Which cloud application produced the anomaly (e.g., computing, messaging, networking)?\nSpecific Model/Component: Pinpoints the exact component causing the issue, allowing administrators to target their troubleshooting efforts.\nThis hierarchical breakdown makes the system more transparent, although it currently stops short of explaining the ultimate "why" behind the specific component failure.\n
\nQuestion:\n Are there standard comparative works that show whether Homomorphic Encryption or Differential Privacy is definitively "better" for F-GNN implementation?\nAnswer:\n To the best of current knowledge, a standard work comprehensively comparing all privacy or optimisation algorithms in a federated graph learning context does not yet exist. However, practical experimentation revealed a significant trade-off: Homomorphic Encryption (offering complete privacy) caused the accuracy to drop to 85%, while Differential Privacy (medium privacy) maintained roughly 97% accuracy. Choosing the correct protocol depends on whether the organisation prioritises maximum privacy or performance.
\nQuestion:\n When comparing F-GNN to centralised or classical models for anomaly detection, how much better is the federated graph approach?\nAnswer:\n Comparative analysis showed that the F-GNN model provided a 15.7% improvement in accuracy compared to existing anomaly detection works, including centralised and flat classification approaches. Furthermore, the F-GNN model is built with the intelligence to automatically tweak its parameters (like learning rates) based on local data characteristics. It is crucial for solving convergence challenges associated with non-Independent and Identically Distributed (non-IID) data in federated environments.\nConclusion\nThe Federated Graph Neural Network framework represents a pivotal step forward, enabling organisations to address massive data volumes and critical, sub-second latency requirements while strictly adhering to privacy protocols.
\nBy leveraging GNNs, Federated Learning, and the efficiency of Hyperbolic Geometry, this approach achieves 99%+ accuracy while maintaining complete privacy compliance. The breakthrough communication efficiency, reaching over 97% communication reduction, makes true, real-time federated learning viable.\n
⁠Next Steps and Future Vision\nThe journey toward fully optimised, secure AI is ongoing. Organisations and practitioners should:\nInvest in Privacy-Preserving Technology:\n Prioritise technology that maintains regulatory compliance while offering a competitive advantage through collaboration.\nExplore Novel Architectures:\n Researchers are encouraged to explore advanced areas like hyperbolic GNN variants and hybrid approaches (e.g., Transformer-GNN fusion) to further improve detection rates, especially since theoretical work suggests HGNN can dramatically simplify hierarchical classification.\nFuture Integrations:\n The framework is built to be future-proof, with planned integration for Large Language Models (for natural language anomaly explanations) and Quantum Computing (for ultra-low latency processing).\n

Federated Graph Neural Networks: Solving Real-Time Anomaly Detection Without Sacrificing Privacy

Introduction\nMoniepoint Research Talks is our monthly engineering chat, where research meets practice. Each month, we host academics and senior engineering experts to share insights that help engineers build better systems, solve real-world problems, and advance their craft.\nIn this edition, Dr Ernest E Onuiri shared his knowledge of precision medicine and his learning from machine learning for cancer detection. The promise of healthcare often feels like a distant ideal, especially when faced with the "one-size-fits-all" approach to treatment. Imagine receiving medicine for malaria that works for some, but not for you, or a cancer treatment that cures one patient but harms another. This disparity highlights a fundamental problem that precision medicine aims to solve: tailoring medical interventions to the individual. But while the vision of customised care is compelling, its widespread adoption faces significant challenges, particularly around scalability, data complexity, and a collective reluctance to embrace change. We will explore the core concepts of precision medicine, delve into the obstacles hindering its scalability, and propose pathways for collaboration between industry and academia to build the trustworthy AI systems needed to revolutionise healthcare.\n
⁠What is Precision Medicine?\nAt its heart, precision medicine is about moving beyond generic treatments to customise care for each individual. The goal is to minimise adverse drug reactions and autoimmune problems that can sometimes be more harmful than the disease itself. This personalised approach relies on a rich collection of data points, including:\nClinical Records:\n Observable features like temperature, weight, and responses to basic questions gathered during a hospital visit. These are generally easy to understand.\nGenomic Landscape:\n The complex internal data within humans often explains why things go wrong internally before external manifestations appear. This data is not easily accessible, expensive to obtain, and requires specialised tools and expertise to interpret, often appearing like noise to the untrained eye.\nImaging Data:\n Various forms of visual data obtained through technologies like MRI, CT, ultrasound, or X-ray.\nSeveral key principles underpin precision medicine:\nPersonalisation:\n Customising medicine for a patient based on their specific needs.\nPrediction:\n The ability to anticipate health events, which enables proactive prevention and treatment.\nParticipation:\n Empowering the patient to participate actively in their healthcare journey, asking questions, understanding the proposed treatments, and giving a sense of ownership.\n
⁠The Scalability Gap: Challenges in Precision Medicine\nDespite its promise, precision medicine encounters substantial hurdles in scaling beyond controlled research environments to widespread clinical adoption.\nData Complexity and Heterogeneity:\n Diseases like cancer are inherently heterogeneous, with various subtypes and severity levels. Genomic data, unlike simple clinical records, is incredibly complex and requires intermediate tools and programming languages (like R) to be unpacked and made intelligible. Combining different data modes (clinical, genomic, imaging) further exacerbates this complexity.\nData Integration and Quality:\n Healthcare data is often siloed, stored in disparate locations (e.g., Lagos, London, Tokyo) and in formats that appeal to local practices, making integration a hurdle for researchers. Furthermore, data is rarely clean, often containing missing values, noise, or being jumbled, leading to wasted research time and unreliable insights. Even long-standing repositories in institutions may not be trustworthy for new applications because the initial workflows were not designed for broad utility.\nCost and Accessibility:\n While the technology exists for genomic sequencing, it remains prohibitively expensive and is not readily available in most hospitals, limiting its widespread application.\nReluctance to Change:\n A significant challenge is the human element – the resistance to adopting new, unconventional approaches. Experienced medical professionals may adhere to traditional methods, viewing new technologies like Electronic Medical Records (EMRs) with suspicion, fearing activity tracking rather than appreciating their potential for record-keeping and knowledge transfer.\nLack of Collaboration:\n There's often a disconnect between academia and industry. Academia might pursue theoretical solutions, while the industry focuses on immediate monetizable products, which are missing opportunities for collaboration. Academic studies, especially in certain parts of the world, often lack the funding and time to generate their own clean, fit-for-purpose data, forcing reliance on external sources.\n
⁠Lessons from COVID-19 and the Importance of Validation\nThe COVID-19 pandemic offered crucial lessons, particularly regarding the need for rigorous validation and the potential of time compression in drug discovery. The rapid development of vaccines, facilitated by in silico (computational) methods, showcased how processes that once took years could be dramatically accelerated. However, this unprecedented speed also led to questions about the longevity and nature of these interventions, as evidenced by the need for multiple doses and boosters, unlike traditional vaccines.\nThis experience underscores that validation is a never-ending process. Engineers and researchers must cultivate a "inquisitive mind" that constantly asks "what if," even when a solution works perfectly. The speaker also emphasises that simplicity often trumps complexity in engineering solutions. While complex models seem more robust, simpler approaches can usually yield equally good, if not better, outcomes with less computational burden and more efficient resource utilisation. Over-complicating solutions just for the sake of it can lead to systems struggling and ultimately failing to deliver effectively.\n
⁠Pathways to Bridging the Gap: The Power of Collaboration\nOvercoming precision medicine's scalability gap demands a concerted effort and a fundamental shift towards synergistic collaboration between industry, academia, and regulatory bodies.\nIndustry-Academia Alignment:\n When industry (with its resources and real-world problems) and academia (with its research and innovative thinking) combine forces, they create something far greater than they could achieve alone. This symbiosis can translate research into monetizable solutions that address real industry needs, as seen in places like Silicon Valley's relationship with Stanford University.\nShared Data Repositories:\n Industry players, especially those generating vast amounts of data, should partner with academia to create shared data repositories. This would allow researchers to use relevant, homegrown data, leading to more tailored findings and solutions directly applicable to local contexts, rather than constantly adapting imported data and solutions.\nCustomisation in Education:\n Education itself needs to be customised to solve real problems, encouraging students to appreciate the practical application of their learning.\nLeveraging Technology for Collaborative Workflows:
\nModern technology has eliminated geographical barriers, enabling remote collaboration. This capability should be fully leveraged to foster interdisciplinary teams that bring diverse perspectives and expertise to complex problems, preventing work in silos.\n
⁠Trustworthy AI: Shared Principles Across Healthcare and Fintech\nThe need for robust, explainable, and scalable AI systems is not unique to healthcare. Industries like fintech face remarkably similar challenges and benefit from similar principles.\nRisk Prediction:\n As healthcare professionals worry about clinical risk prediction, fintech deals with financial risk prediction.\nPersonalisation:\n Precision medicine aims for personalised patient treatment; fintech strives for personalised customer recommendations.\nClassification:\n Disease subtype classification in medicine finds its parallel in customer segmentation and classification in fintech.\nFraud and Anomaly Detection:\n Protecting sensitive patient data and detecting anomalies in healthcare is mirrored by the need for financial fraud and anomaly detection, ensuring data protection and compliance.\nIn both sectors, trustworthy, explainable, and scalable systems are vital for adoption. The computational complexity often seen in precision medicine, which is a tall order, also presents a significant opportunity for innovation and scaling.\n
⁠
⁠Technology: Ability to change data into medicine\nDr. Onuiri's approach to precision medicine involves a structured workflow to transform complex, multimodal data into actionable clinical insights. Building a trustworthy learning system requires more than a robust algorithm; it demands a rigorous, multi-step process from data collection to validation.
⁠
⁠\n\n
⁠Step 1: Multimodal Data Integration and Preprocessing\nThe first major hurdle is aggregating and harmonising disparate data types into a cohesive dataset.\nExplanation:\n Data for a single patient often exists in different formats and locations, such as clinical records from a hospital's EMR, genomic data from a specialised lab, and imaging data from a radiology department. These data silos and varying standards make integration a significant challenge.\nInstruction:\n The initial step is to build a comprehensive patient profile. This involves addressing challenges like \ndata integration\n, handling \nmissing values\n, and cleaning \nnoisy data\n to ensure the quality and interoperability needed for an effective model.\n
⁠Step 2: Feature Engineering\nWith an integrated dataset, the next step is to extract meaningful signals that a machine learning model can interpret.\nExplanation:\n Raw genomic or imaging data is often too complex and high-dimensional for a model to use directly. This critical step translates the data into a structured format, identifying key \nfeatures\n or patterns—like specific gene expression levels or image textures—that correlate with particular health outcomes.\nInstruction:\n Apply domain-specific techniques to convert the raw, multimodal data into numerical or categorical features. For example, specific gene expression levels might be used as features for a cancer classification model, while texture analysis could extract features from an MRI scan.\n
⁠Step 3: Model Development and Selection\nThis is where the "learning" happens. The goal is to choose and train a model that can perform a specific task, such as predicting clinical risk or classifying disease subtypes.\nExplanation:\n While it can be tempting to use the most complex model available, Dr. Onuiri emphasises that simpler, more interpretable models often yield equally good, if not better, outcomes with less computational burden. The focus should be on creating an accurate, efficient, and explainable model.\nInstruction:\n Train various models and evaluate them based on a balance of performance, computational cost, and \nexplainability\n. In a clinical setting, a transparent model clinicians can understand and trust is often preferable to a "black box" algorithm.\n
⁠Step 4: Rigorous and Continuous Validation\nA model is only valid if it is trustworthy. Validation is not a one-time check before deployment but a continuous, iterative process.\nExplanation:\n The COVID-19 pandemic provided a critical lesson in the importance of rigorous validation. A model that performs flawlessly on a historical training dataset might fail when exposed to new, real-world clinical scenarios. Engineers and data scientists must maintain an "inquisitive mind," constantly questioning the model's performance and limitations.\nInstruction:\n Continuously test the model against new data in different clinical contexts. This ongoing validation is crucial for ensuring the system remains \nreliable, safe, and effective\n over time, forming a trustworthy AI system's bedrock.\n
⁠Conclusion\nPrecision medicine holds immense potential to transform healthcare from a generalised approach to a deeply personal and effective one. However, this future hinges on our ability to navigate the complex data landscape, overcome resistance to change, and foster unprecedented collaboration. By promoting a symbiotic relationship between industry, academia, and regulatory bodies, we can collectively plug the scalability gap, build trustworthy AI systems, and unlock the breakthroughs that have long eluded us, leading to better outcomes for everyone.\n

Engineering

Research & thinking

Automating Kubernetes Infrastructure with Crossplane Functions

Turning Messy Data into User Insights: Using Thematic Analysis

How to Protect Fintech Systems from Cyber Attacks in 2026

How to Use Queueing Theory to Stop Your Database from Crashing

Data Connections For Fintech Services

Discovering connections in open datasets

Where you are meant to be

Research & thinking

Automating Kubernetes Infrastructure with Crossplane Functions

Turning Messy Data into User Insights: Using Thematic Analysis

How to Protect Fintech Systems from Cyber Attacks in 2026

How to Use Queueing Theory to Stop Your Database from Crashing

Data Connections For Fintech Services

Discovering connections in open datasets

Unlock exclusive Moniepoint content

Where you are meant to be