Zeta is in the business of providing a full-stack, cloud-native, API-first neo-banking platform including a digital core and a payment engine for issuance of credit, debit, and prepaid products. These products enable legacy banks and new-age fintech institutions to launch modern retail and corporate fintech products.

Zeta currently provides its platform and products to BFSI issuers in India, Asia, and LATAM. Zeta’s products are used by banks such as RBL Bank, IDFC First Bank, and Kotak Mahindra Bank, 14000 corporates, and over 2 million users. Zeta is a SOC 2, ISO 27001, ISO 9001:2008, PCI DSS certified company.

How does Zeta continuously deliver at these high levels without compromising on security? Let us take a look at Zeta’s tech stack to find out.

Server Applications

A server application is designed to install, operate, and host applications and associated services for end-users.

Compute Runtimes

Technology used: Kubernetes, GitOps, Apache Openwhisk, Apache Flink, and Camunda.

Following are the runtime applications in Zeta.

Atlantis is a docker runtime container deployed using GitOps based end-to-end orchestration with the help of Kubernetes.
Aster is an open-source serverless platform run on Apache Openwhisk that runs various short-lived jobs on-demand.
Rhea is an application used to execute BPMN workflows that run on the Camunda platform.
Perseus is an adaptation of Apache Flink to run complex event processing tasks. Apache Flink is a framework and processing engine used for computations at any scale.

We use Camunda to define workflows and automate decision-making.

Apache Flink provides a high-throughput, low-latency streaming engine and supports event-time processing and state management. It has allowed us to perform computations at any scale.

Cluster Management

Technology used: Kubernetes, Kong, and Calico.

A cluster management tool is an essential service used to group the clusters and nodes. This is used to:

Monitor nodes in the cluster.
Configure services.
Administer cluster services.

We prefer using open-source systems in our tech stack. That is why we use Kubernetes as our orchestration system to efficiently manage and deploy containers.

Ingress and API Gateways run using Kong. Kong supports high availability clusters and an extensive range of plugins to address various concerns like authentication, security, and monitoring.

We have also developed 2 in-house tools, Sprinkler and Hades. Sprinkler is our Egress gateway and Hades is our file input/output gateway.

We use the Calico plugin to manage the container network interface.

We are evaluating Istio to adopt it as our open service mesh. A service mesh controls how different parts of an application share data with each other.

Messaging Infrastructure

Technology used: Apache Kafka, Apache Nifi, Apache Flink, KSQL, and Kafka.

A messaging system transfers data from one application to another. We use the following components to seamlessly transfer messages within Zeta’s various applications and clusters.

Apache Kafka is used as a message broker. It allows us to handle high volumes of data and passes messages from one end to the other.
Atropos is a message-based integration bus based on Kafka developed by Zeta.
Apache Nifi is used to implement ETL Pipelines.
Perseus, developed by Zeta, uses Apache Flink to process complex events.
Sinope uses KSQL and Kafka connectors to bridge the message/event world and the batch/file world. KSQL and Kafka connectors enable rich data integration and streaming.

Data Stores

Technology used: Postgresql, Amazon S3, Amazon RedShift, ClickHouse, and Redis.

Postgresql is used to store transactional data and Amazon S3 is our data lake. We use Amazon RedShift and ClickHouse as our data warehouse and Redis, an open-source memory data structure, to store cache.

Application Performance Monitoring (APM) and Business Performance Monitoring (BPM) uses the ElasticSearch engine.

Data Processing

Technology used: Presto SQL, Sparta, and Apache Superset.

The data processing unit is an essential part of any server application. It converts data available in the system (machine-readable data) to a human-readable format.

We use the Presto SQL query engine to process big data and Sparta for stream processing. Stream processing allows us to convert data in motion directly to continuous streams.

The Power Centre stores various data models and allows us to modify data and enables the reuse of data. The Power Centre is an adaption of Apache Superset.

CI/CD

Technology used: Jenkins, ArgoCD, and Sonarqube.

Jenkins is used for Continuous Integration (CI) and ArgoCD for Continuous Deployment (CD).

Our servers use Sonarqube, an open-source platform, for static code analysis.

Observability

Technology used: Grafana, Kibana, Fluentd, and Hypertrace.

Observability is defined as the ability of the internal states of a system to be determined by its external outputs. External outputs can be anything such as alerts, visual representation, and infrastructure tracing.

We have developed Prometheus as our event monitoring system. Prometheus stores all metrics in the database.

We use Grafana for our dashboards and alerts and Kibana for log analysis. The purpose of both these applications is to visualize and navigate data. We also use Fluentd, an open-source data collector, for logs and metrics collection.

All applications should have a distributed tracing system. Hypertrace is our tracing system. It helps us debug applications and log information about their execution.

Security Monitoring

Technology used: HELK and Jackhammer.

Security monitoring is another essential unit to analyze data to detect any suspicious behavior or changes to the network.

HELK is an ELK (Elasticsearch, Logstash & Kibana) stack with advanced hunting analytic capabilities provided by the implementation of Spark and Graphframes technologies.

Kratos, an in-house adaption of Jackhammer, is our Security CI.

We are evaluating RockNSM, a premier sensor platform for Network Security Monitoring (NSM) hunting and incident response (IR) operations.

Hardware Security Module (HSM)

Technology used: Safenet, Gemalto and nCipher/ Entrust nShield Solo.

HSM manages digital keys, encryption and decryption, and provides strong authentication. We use the following HSMs:

Safenet and Gemalto as Network HSM.
nCipher/ Entrusy nShield Solo.
Harpocrates, developed by Zeta, is our HSM as a service interface.

Mobile Application

Technology used: Firebase Hosting, Websockets, HTTPS.

Languages used: Kotlin, Java, Objective C, Swift.

We develop mobile applications as native apps, React Native apps, and web apps.

Kotlin and Java are used to develop our Android applications and Objective C and Swift for our iOS applications.

Firebase Hosting helps with Analytics and Crash detection in the server. Websockets and HTTPS make it possible for two-way communication between the server and the user.

Web Applications

Technology used: Typescript, SCSS transpilers, Vue.js, Bulma, Buefy, Webpack, Rollup, Verdaccio, Lerna, and Sentry.

Languages used: HTML, CSS, Javascript, Node JS, and Express JS

We use HTML, CSS, Javascript, Node JS, and Express JS to develop our web applications.

Typescript and SCSS transpilers convert program code from one language to another.

Vue.js is our Javascript framework and Bulma is our CSS framework. Buefy is a user interface component and is made using both Bulma and Vue js. Webpack and Rollup are the JavaScript build tools.

Verdaccio, an NPM registry, serves the purpose of a Private NPM repository. The repository is managed by Lerna, a workflow optimization tool. Sentry, an Application monitoring tool, is used to monitor errors.

Cyber Security

Technology used: Trivy, Clair, CloudSploit, MobSF, ZAP

The challenge when building a product is how we balance ease of use with security. At Zeta, we use Trivy for CI docker scanning and Clair for CD docker scanning.

CloudSploit is our Cloud Security Posture Management. We use MobSF for mobile application security.

ZAP for web applications is all in CI/CD.

Best Tech Stack = Best Performance?

Building a system that can provide these functionalities and process over 1 million transactions per second is not easy. While Zeta uses the best tech stack, building a robust framework to continuously deliver at the highest levels without compromising on security would not have been possible without Zeta’s talented engineers.

The challenge when building a secure mobile application is how we balance ease of use with security. Applications that are easy to use are the ones that succeed. However, any compromise on security could have disastrous consequences. Mobile applications that handle payments have more stringent security protocols when compared to utility applications. However, to succeed, it has to be just as easy to use.

These were the topics of discussion at Rootconf’s Data Privacy Conference held in April 2021. The roundtable, moderated by Suman Kar, included Madhusudhan Sambojhu from Able.do, Chirayu Desai from Calyx Institute, and Apurva Jaiswal, Engineering Manager at Zeta.

Zeta develops cloud-native mobile-first banking and payment platforms that meet these exact requirements. We aim to move away from lengthy checkout forms and OTP-based payment authorization. Our platform allows merchants to securely accept payments from around the world and allows customers to make these payments with a single swipe.

Let us discuss some of the security principles we follow at Zeta when designing our mobile applications.

Zero-trust Principle

Adopting a zero-trust approach is important when it comes to securing data on applications. Organizations building the application should ensure they have implemented all necessary security measures to protect user data. They should not depend on the application hosts for this.

There are 2 types of data that we need to secure in mobile applications:

Data at rest.
Data at motion.

All sensitive data should be saved in vault storage and should be accessible with explicit consent from the user.

Since mobile devices are sandboxed from day one, it helps protect application data, stored on the device’s internal storage, from hackers and other applications on the device. Some tools that can be used to secure data are Charles proxy, Wireshark, Firebase, and SonarQube.

[su_youtube_advanced url=”https://www.youtube.com/watch?v=f-boD_oQ5ts&ab_channel=PhaniMarpaka” autoplay=”no”]

At Zeta, we ensure user data is opaque to the cloud provided and is end-to-end protected. We distill and sanitize the network edges. We ensure end-to-end authentication and access control using IAM and RBAC.

Listed below are some best practices we have adopted at Zeta when building mobile applications.

Mobile Application Security

Mobile application security is the measures taken by the application developer to secure the applications from external threats. A breach in mobile security gives hackers access to the user’s personal information, their current location, banking information, and much more. Some best practices are:

Perform root checks using Google SafetyNet API and Rootbeer. On iOS devices check for functions that should not be available in a non-rooted device.
Use SSL Pinning to prevent attackers from analyzing your application functionality and the way it communicates with the server.
Build strong and customizable authentication flows: — Phone number + OTP, Phone number + OTP + password
Do not allow concurrent logins.
Analyze user behavior and trigger re-authentication in case of risks.
Have a strong device binding ID (Device ID + Sim ID)
Do not issue tokens when the device binding ID changes.
Server triggered data wipeout.
Screen record and screen capture protection.
Launcher image protection.

APK Security

It is not enough to secure your application while it is being used. It is critical to ensure your application is hosted and distributed from a secure platform. This prevents hackers from gaining access to your code repository and exploiting it to gain unauthorized access to user data. Some best practices are:

Never distribute APKs through APK/IPA files. Use standard firebase app distribution/testflight.
Never release debug builds.
Assume whatever goes in APK is public information :- The Native Development Kit (NDK), Prefer server-side secrets
Implement code obfuscation.
Incorporate proguard rules in your builds.

Identity Establishment and Authentication

When onboarding a customer on your mobile application, it is important to establish their identity. This allows us to ensure only that person has access to the application on their device. Some best practices are:

Challenge a user using multiple identity vectors such as phone number, email, bank account number, and password. Challenges should be sent on different communication channels
Each vector is identified by a specific IdP.
Implement Social Authentication.
Use penny testing to verify a user’s account.
Successful authentication leads to a 256 bit AES symmetric key between server and client using ECDHE-ECDSA-AES256 bit key exchange.
Subsequent device sessions are established using OATH-based HOTP of monotonically increasing session count.
256 bit Symmetric Keys.
OATH-based HOTP for authentication.
Key setup using ECDHE-ECDSA-AES256 bit.
Real-time locating system (RTLS) optimized transport based on TLS 1.2. : — Key exchange through ECDHE-ECDSA-AES256 bit key (Equivalent to RSA 372 bit), Encryption, authentication, and integrity check through AES 128 bit in counter mode with SHA-256 based HMAC.

Transaction

Securing transaction data is the most important aspect of mobile security. Any vulnerabilities here can lead to the application user losing money and cause irrevocable setbacks to your application.

Non-repudiable transactions.
Private keys protected using Secure Module on Device or Password+Scrypt.
Non-verifiable random key material on the device.
Key rotation after every successful online transaction.

Assume the mobile application code/library is public

This should be the basic assumption an organization makes when building a mobile application. To ensure there are no compromises to an application’s security, organizations need:

Ensure their mobile team is kept up to date with and implements the latest security guidelines and practices in the industry.
Ensure all security checks and protocols are enforced when deploying code.
Have their mobile application regularly audited by external auditors.

[su_youtube url=”https://www.youtube.com/watch?v=VRBPbQYoytY&ab_channel=PhaniMarpaka”]

At zeta, we believe in building and nurturing a strong team that understands security and follows the importance of:

Code peer reviews.
Static application security testing.
Regular security testing team by Zeta’s internal security team.
Regular application security testing by 3rd party vendors such as SISA.

Conclusion

There cannot be any compromise in terms of security when building mobile applications. Apart from setting up security protocols, organizations should ensure their employees are kept up to date with the latest trends in security. Organizations can use tools to enforce security protocol and ensure their applications are secure.

It is also important to educate end-users about best practices around mobile applications. Users should only download applications from trusted application hosts. Downloading applications directly from a website or elsewhere could lead to security breaches.

Zeta Suite is rethinking payments from core to the edge, algorithms to form factors, applications to solutions. Having built a modern stack that Financial Institutions (FIs) can use for debit, credit, and prepaid cards, loans, authentication, and Fraud and Risk Management (FRM), Zeta invites you to join their journey in democratizing payments. Check out the openings on < careers.zeta.tech >

Thanks

Engineering @Zeta

Tag: MobileInfra

Zeta Tech Stack