Wallet 2.0

Posted on April 5, 2021 by Phani

Wallets are the most basic thing a person has had since early times. We needed something to put our money in clusters for our daily utilities, one cannot access an ATM for every single time of purchase. Now, a digital version of it came called e-wallet, which can provide aggregation capability for payment-related instruments for ease of use, which allow customers to pay for purchases digitally.

Wallet 1.0

Let’s discuss a basic model of Wallet 1.0. It provides an aggregation over a bunch of supercards and accounts. Supercards are the debit or credit cards managed by Zeta and can be either physical or virtual.

The wallet is also associated with accounts (or cloud cards), some of the examples of cloud cards include meal cards, cash cards, and communication cards, which you can see in the Zeta app. Debit or credit occurs at these accounting instruments, and these accounts are hosted in the Aura** domain for Wallet 1.0.

Coming to the payment plan generation, when any transaction is initiated by the customer using their Super card, first, the wallet linked with the super card is identified. Now, let’s say there are three accounts that are linked with the wallet: meal, communication, and cash card. Consider a case where we initiate a transaction for 100 bucks using a Supercard at Mcdonald’s. First, the wallet linked to the Supercard is identified. For that wallet, let’s say, there are three accounts linked: — corresponding to the cash, communication, and meal card. To identify which of a user’s account to debit, by how much and in which order, wallet generates a payment plan. On the basis of various parameters in the incoming payment request and the applicable account selection rules, eligible accounts are filtered. Some reasons why an account can be filtered out include: exceeding the max daily or monthly spend limit, exceeding the max transaction limit or payment may only allow a particular currency account to be used. In our example, let’s say due to certain restrictions, the communications type account was filtered out.

After this filtering, the accounts are ordered on the basis of the suggestion strategy. This ordering decides how one or more accounts are to be debited for the payment. So, while purchasing food items, it might be preferable to debit the meal card first and then debit the remaining balance (if required) from the cash card. So, for the transaction at Mcdonald’s, in case our meal card does not contain sufficient funds, the generated plan may suggest something like debit $90 from the meal account and $10 from the cash account.

Once this is done, a final ordered sequence of accounts, along with the proposed debit amount, is presented to the payment engine, which further acts based on this plan.

Why Wallet 2.0?

Wallet is an aggregator of supercards only rather than a generic pool of payment instruments
Violating separation of concerns
Wallet shouldn’t be responsible for aggregating payment instruments
Wallet is performing payment instrument authentication
Wallet’s payment accounts are only from Aura** domain
Wallet is tightly coupled with #Zetauser
No wallet product specification exists

Wallet 2.0 Design

A wallet product acts as an umbrella or specification for a wallet which is a materialization of the wallet product and inherits its properties from the product.

The definition of wallet product provides the capability to manage wallets — their selection rules, suggestion strategies, and other flags and attributes at a top-level.

Similarly, a payment account product governs the definition/schema for payment accounts. Each payment account product is linked with a payment account provider which acts as an interface to the actual account provider (like Google Pay/ PayTm).

We can perform operations such as to get account balance for example through this interface.

Coming to the payment side of the picture, let’s say the user in BigBasket is saving a VISA card, a corresponding payment account would be created for it. Then, he/she adds another MasterCard, corresponding payment account would be created and added. The Payment Account Product here could be modeled as payment types such as VISA and MasterCard as the semantics of authentication and transaction workflow depends on these. Now, for a VISA payment account, when say get balance is needed, it would reach out to the Payment Account Provider which could be Aura if we are maintaining the account here at Zeta or Shadowcard which would reach out to the VISA network to get the balance (detailed example).

Now, having all things together, when BigBasket asks for a payment suggestion for a user, the configured selection rules and suggestion strategies are applied for that wallet’s payment accounts while taking the help of Payment Account Providers in order to generate the payment plan which can be passed back to BigBasket.

Thank you

Notes:

** Aura cluster is the core digital accounting system also termed as the heart of the financial systems of Zeta. Any financial transaction to be effected would be accounted for and recorded in Aura. It helps to keep track and manage the financial information of Zeta’s Business Clients. Aura has the ultimate authority in approving/rejecting a financial transaction.

Speakers — Siddharth Sharma & Praveen K L

Edited by Phani Marupaka

Achieving 1 Million TPS with Zeta’s Cipher – A new benchmark in the Payments Industry (Part 1)

Posted on March 30, 2021 by Phani

Introduction

We marked 22nd Jan 2020 as a historical day of significance for Zeta and the future of payments! We were able to successfully showcase 1 Million Transactions per Second (1M TPS), illustrating the scalability and elasticity with which banks can handle online transactions.

Background

In December 2019, we launched Cipher, a cloud-based Authentication as a Service solution that provides an easy way for the issuing banks to participate in online transactions, adhering to the 3D-Secure protocol as laid down by EMV Co.

With Cipher, the issuing banks can provide modern, cutting-edge, and secure card authentication services to their cardholders. To unveil the robustness of the service, i.e., the amount of authentication load that can be handled at the highest success rate (99.9%), we planned to simulate 1 million online authentications.

To put things in context, currently, the maximum online transaction volume across India is approximately 4160 per second, considering the transactions processed across all of the electronic payment channels like UPI, Visa, Mastercard, Rupay, NEFT, and IMPS. You can find the reference calculation here.

When we say Cipher can handle 1 million authentication requests, it is 240 times more than the number of payments being processed in India by all of the big players put together.

This estimate gives us an idea of the incomparable scale at which Cipher can handle authentications, relieving issuers and merchants from the persistent problems of scalability and reliability during flash sales and other peak load scenarios. Besides, We have built Cipher in such a way that it is elastic, so no resource gets wasted. When there is an increase in the request volume, the systems self-provision the resources from cloud providers and relinquish the same when the request volume decreases.

Importance

Why is this important to us? The first reason is that we want to enable issuers to authenticate as many transactions as possible, with the highest success rate and reduced revenue loss. Naturally, issuers will be able to handle any amount of eCommerce sales at all scales that merchants can imagine. When Cipher can do all of the heavy liftings when it comes to online authentications, issuers have the comfort of focusing on their core bank offerings rather than worrying about server overload and authentication failures.

The second reason is more personal. We want to convey that ‘scale’ is a solved problem with Zeta. As more and more commerce progresses online, it is natural to expect that the payment authentication solutions will run at this internet-scale.

We believe that all of the consumer-facing banking and payment services should be as scalable as Google Search at peak loads. We want to exemplify this with our Cipher demonstration. We want to assure the banks that they don’t have to worry about scale anymore.

Demo Details

In the dashboard, the number on the left indicates authentication requests being handled by Cipher in reqps. The middle number shows the maximum number of requests at the current computing capacity in the selected time window (5 minutes). Towards the right, we have the number of pods (systems) of Cipher that are up and running to handle the required load. In the central region, we have the success rate of the authentication requests.

As one can notice, during the video

The number of requests handled per second increases from 18 reqps to 1 Million reqps in about 3 minutes.
The success rate of handling the authentication requests stays constant at 100% throughout the demo.
When the load is lightened, the number of computing pods required for handling 1 Million TPS shrinks back to a smaller number showcasing how Cipher auto-scales.

As Cipher’s systems are horizontally scalable, they are limited by the computing and storage units built into them. So, by any means, this high load of 1 million TPS does not indicate the maximum ‘capacity’ of the systems. Cipher can extend to the internet-scale and shrink to a single node footprint, based on the needs. We think we demonstrated that alright. 🙂

Scope Inclusions

In the above demonstration, we have simulated:

Mastercard Card Network to demonstrate the authentication initiation requests (as per the 3DS authentication protocol) that get dispatched to the Cipher system.
Swipe2pay authentications – to simulate user engagement while fulfilling the authenticating challenges.

Scope Exclusions

User interactions for authentications to do away with the additional time
Risk and fraud checks

Key metrics

Resources used (Cipher)
1. Units: 350 server instances (all microservices incl.); (Kube cluster running on 200 m5.xlarge EC2 instances)
2. Memory: 8 * 360 GBs
3. CPU: 4 * 360 vCPUs
4. Bandwidth (if available)
Resources used (Load Generator)
1. Units: 50 * c5.4xlarge EC2 instances
2. Memory: 32 * 50 GBs
3. CPU: 16 * 50 vCPU
4. Bandwidth (if available)
Verification mechanism used
1. JSON web signature.
Test Data Structure
1. Banks: 50
2. Card BINs: 500
3. Cards per BIN: 10000
Average response time per request: 100ms
Hops per each request within Cipher cluster:
1. VEReq: 1 hop
2. PAReq: 2 hops
3. Submit Swipe2Pay challenge: 3hops

Conclusion

We honestly believe that the 1 million TPS demonstration has set a new benchmark for payment authentication solutions. We are also delighted that we were able to pull this off in a short period of 9 days. Although we didn’t have enough time to explore a lot of other frameworks for additional optimizations, we think we did great in the time we had!

It’s also worth mentioning that our systems are capable of scaling more than 1 Million TPS when necessary. We hope that cloud technologies get widely adopted by issuers in the Payments Industry to be able to improve their offerings for their customers significantly.

We have a part two which delves into the core engineering aspects of the demo for the relevant audience. Thank you!

Part 2 of the blog

Credits

Developers who made this feat possible – Mrinal Trivedi, Amit Raj, Ramki, Dipit Grover, Amit G, Shubham Jha, Vivekanand G, Mohd. Tanveer, Shaik Idris

Author – Preethi Shreeya, Phani Marupaka

Elements of a “complete” product spec

Posted on March 25, 2021 by Phani

A lot of us product managers have struggled with the craft of creating “complete” Product Specs/PRDs. This leads to engineers having a lack of clarity on what needs to be built, sales and business not being aligned in terms of what is being built vs what is being sold as well as executives and other stakeholders having a lack of clarity in terms of what exactly the vision and strategy of the product are in the product manager’s mind.

There’s a quote from “System Engineering Fundamentals” for Product Requirements:

“Determine the needs or conditions to meet for a new or altered product, taking into account the possibly conflicting requirements of the various stakeholders”.

For the definition of a product specification, they promote proper documentation for a precise idea of the problem to be solved so that the designing would be efficient and the cost of design alternatives can be estimated.

A spec should be crystal clear and technically concise that doesn’t cater to any ambiguity which makes it the engineers easy to understand what they are actually going to work on. When we go deep down into the spec, it is much like a game plan which is made to act strategically with our product or service to achieve our goals.

The spec should clearly answer the What, Why, How, and When something needs to be solved. It should be the single source of truth for the particular feature/product which the engineering team can refer to and clearly begin on the solution with full clarity.

There are some amazing companies out there that do excellent documentation for Product Specifications/PRDs like Google, Facebook, Uber, and Microsoft. What are they doing right?

There are so many elements in a product spec that are specific to the type of industry you are working in, whether you are working in a B2C or a B2B company, an early-stage company, or a company with a mature product line, etc.

Let’s go over some of the elements that make these specs really “complete” :

Goals should be SMART: Specific, Measurable, Attainable, Relevant, and Timebound. An example of a bad goal would be- “Make system XYZ faster”; since what defines “fast” or “faster” and when do we know whether the goal is met or not?

Assumptions: Don’t assume that the assumptions made are known by the engineers, leadership, or any other stakeholders, convey all the assumptions clearly before that have been made as a baseline before starting a particular spec.

Non Goals: We tend to keep our focus on ‘do this to win’ but it’s also important to figure out what ‘not to do’ as well. This prevents scope creep and helps us focus on the right things. So clearly call out things that you are NOT chasing.

Target Audience & User Personas: Discover your target group of people with different personas who will be affected by your feature. Before writing individual feature specs, it’s good to know the product’s relevancy for the particular audience you are targeting and how it will affect them.

Data Analysis/Complete Analysis: Publish the data analysis your team has done to give an insight into the problem statements or the solutions which you’ve chosen to build. This gives a clear metric-driven insight into the product strategy.

Hypothesis: Companies like Facebook and Uber run hundreds of tests/hypotheses every single week. For a B2C product, clearly call out any hypothesis that you are going to test with this particular feature release.

Feature List Table: The feature list table is a short summary of the whole spec which lists down all the sub-features with priorities, owners as well as calls out any other cross-team dependencies. This helps the engineering team plan out the feature efficiently and carve out individual sub-tasks and tickets.

Features in Detail: Document the complete description of the feature in detail. Based on the type of feature it should include wireframes/flowcharts/pseudocode for functional and business understanding. Wherever applicable, link to the UX design which lets all the stakeholders understand how the design should be.

Clearly call out the internal/external dependencies.

Deployment Plan (GTM Strategy): Define how you would want to launch your feature. Is the feature being launched in a phased manner as per user groups/geographies or as per some other pivot?

Metrics: List out all the success metrics to be tracked. Depending on the type of the feature, you can use metrics frameworks like AARRR (Acquisition, Activation, Retention, Referral, Revenue) or RED (Requests, Errors, Duration) or CSAT/NPS.

Anti-Metrics / Counter Metrics: Document the risks posed thanks to your feature. What are the metrics to be tracked to manage the risk? What’s the risk mitigation plan?

In concluding, here are some of the specific domain-related features you should be cognitive of, starting from Security Sign-off/Audit Sign-off/Privacy Sign-off for your privacy concerns, Localisation for international features that deliver support for different languages, Future Enhancements involves future vision with the plan and phases for the product, Appendix in which any kind of stuff you want to add, epic/ticket links, etc.

Thank you.

Credits

Speaker- Anand Kulkarni

Blogged by – Nupur Chandra & Phani Marpaka

Video Edited by Nupur Chandra

Failure of MasterCard transactions

Posted on September 30, 2017 by Ramki Gaddipati

My sincere apologies to all users who are affected by the current outage on Mastercard transactions.

Zeta is connected to the Mastercard network through a prominent card processing service provider, which unfortunately is facing a serious outage that has lasted for over 28 hours now. The service provider is also unable to provide a disaster recovery path due to reasons unknown to us. This is absolutely unanticipated and unacceptable. However, at this moment, we can do little as there is no other practical alternative to reach the Mastercard network.

We are closely monitoring the development at our service provider’s end and will keep you posted on the progress.

The issue is really painful to all of us at Zeta. There could not have been a worse time for this, especially given the festive season. We are deeply sorry for the inconvenience it is causing you. We always strive to make your Zeta experience outstanding, please do not allow this to disappoint you.

We are grateful for your patience and support.
Wish you a joyful Dussehra.

Best wishes,
Ramki
CTO, Co-Founder

Digital Meal Vouchers

Posted on July 24, 2016 by Ramki Gaddipati

Maintaining an account of some value and supporting debits and credits on that account is an elementary exercise that a computer science student picks up in a Database course. Hundreds of accounting systems have been built across the world with about as many different implementations of these basic rules, and a proposal for a brand new accounting system could be considered as reinventing the wheel. But new accounting systems were built — Bitcoin, dozens of Altcoins, interbank distributed ledger systems like Ripple — achieving the same purpose of maintaining a ledger of accounts, but in fundamentally different ways. Across the three different systems of Bitcoin, Ripple and an Islamic Accounting System, the definitions of a ledger, a transaction and the transaction rules have very little in common. Their governing principles are so distinct that they needed fundamentally different systems.

Compliance with unique laws and regulations demand unique software systems.

The Meal Vouchers as defined in the Income Tax Act Rules, 1962 and the various prevalent interpretations of the same led us to build a one of its kind system to hold funds and enable transactions. The prevalent rules state that an organisation can provide tax benefit on an employee’s meal expenses if and only if the value is provided in the form a ‘paid voucher’. Such a voucher should also be non-transferable and only a fixed value of Rs. 50 per meal may be given.

At Zeta, one of our objectives is to eliminate paper transactions. We’ve tried to identify an available electronic system that can adhere to the requirements of Income Tax Rules for Meal Vouchers. We investigated stored value electronic cards like Smart/Chip Cards and NFC Cards, conventional mobile wallets, prepaid and core banking systems and the cards backed by such systems, and concluded that none of them could comply with any acceptable definition of a ‘voucher’. None of these systems hold value in discrete units of Rs. 50 each, like how a paper voucher can hold. Interpretations that an electronic payment card complies with the definition of the voucher in the Income Tax Rules have been vehemently contested and a majority of reputed auditors have taken a position to the contrary. The Income Tax Rules published in 2009 have solidified the distinction between voucher and an electronic payment card by providing different set of rules for electronic cards from that of vouchers. The current rules do not even recognise electronic cards. If electronic cards do not meet the requirements of a meal voucher then any other traditional mobile wallet or NFC card will also not meet those requirements as the principles of accounting and transactions are the same among all the systems. From our discussions with several auditors and compliance officers of various companies, we learned that they want a real paper voucher like solution to meet this requirement. So we compiled all the laws defining and governing electronic documents, negotiable instruments and payment systems in India and created a Digital Voucher system that forms a crucial building block of the solution that complies with Income Tax Rules.

Any of the general, legal, wikipedia and other dictionaries define Voucher as a written document with a certain value that can be exchanged for goods or services. To digitise a written document and to provide the credibility offered by a signature while being compliant with the definition of written document, we had to rely on Electronic Documents and Digital Signature definitions as specified in Information Technology Act 2000. To define an instrument that can represent a promise of certain value, we had to consult Negotiable Instrument Act (Amendment) 2015. To define a method of exchange of such documents and to issue documents representing a value, we had to refer to Payment and Settlement System Act, 2007 and the Guidelines to Issue Prepaid Instruments published by Reserve Bank of India.

By drawing from all the relevant laws of India, we created a Digital Voucher – a digitally signed, electronic document bearing a unique identifier and representing a specific value in Indian Rupees, issued by a Bank to a beneficiary unambiguously identified through a phone number, email address or any other such reliable, unique identifier.

We have built a system that mints Digital Vouchers on demand, using hardware security modules to create secure digital signatures as defined by Certifying Authority of India. We built a wallet that can hold these vouchers of a beneficiary. We developed a transaction system that can transfer vouchers from a beneficiary’s wallet to that of a merchant’s after due authentication and authorisation in compliance with the Reserve Bank of India’s guidelines. We created a settlement system that can interoperate with IMPS and NEFT systems of NPCI and also with card associations like MasterCard.

Using this unique system of Digital Vouchers, we built a Meal Voucher system wherein no voucher issued is more than Rs. 50 each and is non-transferable. We added multiple subsystems which identify the nature of the business of the merchant involved in a transaction and to disallow a meal voucher transaction if the merchant is not a recognised food seller. We built a system to allow full and partial refunds that work with vouchers. As the network connectivity proved unreliable even in the metros of the country, we also devised a mechanism to enable offline transactions using these vouchers.

These unique characteristics of our system make our Digital Vouchers as usable as paper vouchers:

Without Internet Connectivity
Without Power
Without Smart Devices
Without a steep learning curve

In addition to retaining the advantages of the paper, our system provides compliance controls that are unimaginable with paper – the details of the beneficiary of a voucher are embedded at the time of creation of voucher, in every transaction the beneficiary is authenticated with multiple factors or the vouchers can’t leave the user’s wallet. Thus making our vouchers non-transferable, mitigating one of the major weakness of paper vouchers.

To summarise, Zeta Meal Vouchers are digital vouchers generated per each employee and are immutable and non-transferable. Each voucher bears value of Rs. 50 or less per meal. Vouchers are distributed to employee’s wallet on the cloud. Employee can access and use them for food through Mobile App, Super Card, Super Tags and other means after due authentication.

To deliver the most visible benefit of convenience with our Digital Vouchers, we had to tame the devil in the details of compliance. In our interactions with various companies, we realised that different companies have different views and policies for meal voucher benefit to employees. There are several companies who never adopted paper vouchers because they believed that they are non compliant – they are not non-transferable and the usage is not truly restricted.

We made the entire system completely configurable per company. Companies can choose if the usage of the meal vouchers have to be restricted to specific vendors in their office, vendors they have tie-ups with, vendors Zeta has tie-ups with, merchants recognised as food sellers on card networks, Zeta certified food sellers or all recognised food sellers or any combination there-of. Companies can restrict the days and time during which the meal vouchers should be usable, maximum value of the transaction permissible and how to treat the unutilised funds in the meal vouchers at the end of the financial year. That is, we have given all possible levers and knobs for the companies to define the system as per their policy. Better yet, the system can interoperate with several payroll softwares and the value of meal vouchers to be disbursed in any given month can be computed and administered seamlessly.

Each of the subsystems like Minting, Wallet, Transaction Processing, Core Accounting system, Card Network Gateway, Merchant Curation, etc., that compose our Digital Voucher System deserve an exclusive post each to discuss the unique advantages they bring and the deviations we had to make from traditional approaches to achieve them.

NOTE: Voucher is only a foundational element in compliance with the Income Tax Rules, 1962 Section 3 (7) (viii). We don’t intend to favor any interpretation of the rule over others. Our objective is to provide all the necessary ingredients to companies to compose a solution as per their policies. Over 200 companies have chosen to use this solution with at least 2 dozen unique policies that are different in many important ways.

Trusted Contacts

Posted on July 17, 2016 by Ramki Gaddipati

Protecting access to sensitive information and providing strong authentication for all financial transactions is expected of any financial app. However the hardware limitations, platform semantics and the lack of knowledge of most users make the hard problem of securing access harder.

Authentication is usually done based on either what user knows (password, PIN, etc.), what user has (token, chip card, etc.), or what user is (biometric data). The password based model that is still being used by many financial apps and services is fraught with security vulnerabilities. Services often rely on additional, second factor authentication in the form of a one time password (OTP) sent through SMS. This model is reasonably secure in the desktop browser world, but it is broken in the android world, since most apps and most human attackers can access the data stored on an Android device, such as the SMS messages.

We believe that the password model, the OTP model and models that combined the two are unreliable for a financial application. Biometrics based approaches are impractical for a large number of Android users. We couldn’t always rely on what user knows, as it was impractical to expect all the users to be cautious in both specifying what they know and to not share the same information with others. We brainstormed a few approaches that rely on what user has and what user is. Trusted Contacts is one such model that relies on both what user has and what user is in an interesting and simple way.

Trusted Contacts relies on humans as the challengers and the verifiers of identity. Humans naturally use biometrics and other ambient signals to authenticate people in everyday interactions. This process is too complex for a machine to emulate and is practically infeasible. With Trusted Contacts, we wanted to rely on this natural power of humans and convert the result of such authentication to a value which is easily representable, transmittable and has sufficient entropy. Such a value, can then be presented to the system and be used for authentication by the user who was challenged.
A user first sets up his Trusted Contacts by nominating a set of at least 3 contacts identified by their mobile numbers. The nominated contacts need not be users of our system. The contacts are informed about their nomination and their role in securing the user’s account. They are told that when the user attempts to re-login from a clean state they will receive a code from Zeta. The contacts are requested to ascertain the identity of the user before they share the code they received.

Select a subset of contacts you Trust to Setup "Trusted Contacts"

When an existing user attempts to login, he is challenged with OTP based first factor. After successful authentication with an OTP, if the user has his Trusted Contacts setup, he is challenged to provide authentication codes from at least 2 of the nominated contacts. The User indicates the contacts he would like to rely on in this particular instance. Zeta sends codes to those contacts along with a brief reminder about their role in this exercise. The user is expected to get in touch with his trusted contacts and receive the codes. If the user provides the right codes, he is given access to his account with Zeta.

Select the Trusted Contacts to authenticate with

Enter code given by Trusted Contacts to complete authentication

During authentication, the interaction between User and his contacts is unknown to the system. The system does not provide any hints other than the name (and possibly a picture, in the future) of the contact as known to Zeta, on how to contact and/or how to establish identity. Authentication codes are securely generated 4 digit random numbers and are specific to the current authentication session of the user. As of now, the authentication codes are sent to contacts by SMS. If the contact is a Zeta user as well, we intend to use secure channels to communicate authentication codes. We intend to provide hints to the contacts on how they could challenge the user, so that they are alerted to the sensitivity of the role and can fulfil it meaningfully.

If the contacts play their role reasonably well, we believe this model will be highly reliable. Given the required human interaction involved, it will also be a very unattractive target for computerised attacks. While the contacts are also likely to have Android phones, we have tried our best to make the auth code SMS messages not usable by malware and spyware.

The success of this feature and thereby the reliability of the security it can offer hinges a good deal on the user education and the overall user experience. We have done several iterations to arrive at the current interactions. We do believe that there is a lot of room for improvement in the overall Trusted Contacts experience. However, we think it is sufficiently ready for initial adopters and to gather feedback. We would love to hear what you think!
NOTE: Trusted Contacts in isolation is not sufficient security measure or a complete authentication approach. This is only one of the elements of a more elaborate system and application security model and relies quite heavily on other modules of the model to provide the security we rely upon.

First Post

Posted on January 29, 2016 by Ramki Gaddipati

When I started conceptualising Zeta, it appeared like a great startup opportunity. Once Bhavin and I started working on it, the canvas began to expand everyday. A great many doors opened to us, each one enabling us in new ways, and soon I stopped seeing this as merely an opportunity. A few months into Zeta, I realized that this is my life’s work.

The impact that Zeta can have in the lives of millions of indians is massive, and we at Zeta want to make the journey itself count, and not just its end. Irrespective of commercial success, it is going to be a memorable one. 🙂

People at Zeta have built custom secure kernels to run our servers, a one of its kind non-repudiable transaction system, algorithms to optimally deliver location based services in a bandwidth constrained country, and a disintermediated transaction system that works completely offline. However, we believe this is just the beginning. We are building the foundation for what we believe could be a platform that will help India and the world transact digitally, easily and securely.

Zeta is a technology company. Not e-commerce, not banking, not travel, not food, not entertainment and not many other things. We are just a serious technology company. As such, we attack problems at the fundamentals. We work on cryptography, complex systems and algorithms. We build simple and elegant software that solves large, everyday problems. Some of these problems have been untouched for decades, and some have been attempted by hundreds of companies with no appreciable result. We believe that solutions to such problems require not only great technology but also great empathy for the users and intimate knowledge of building beautiful and highly usable interfaces. At Zeta, we have gathered some of the most talented people in the country to build products, systems and interfaces. We constantly seek to bring great people into the team who will make us learn more, do more, strive more.

The nuts and bolts of serious technology is usually hidden from the users. I hope that this blog will be a place where we write about the technology we are building, using and learning. Here we would like to discuss some of the intricacies of our products, hear feedback, collaborate with our users and engage with the engineering community at large.

Wow, it feels real special to be writing this first post on zeta.tech blog. 🙂

Wish us good luck! 🙂

Architect and co-founder of Zeta,
Ramki

Engineering @Zeta

Category: Uncategorized