Pagos Digitales - Foco en America Latina

Luca Napoli
March 15, 2023
#Finance

Impulsado por las nuevas tecnologías y las tendencias globales, el mercado de pagos digitales está floreciendo en todo el mundo. Con una valoración de más de $68 mil millones en 2021 y expectativas de crecimiento de doble dígitos durante la próxima década, los mercados emergentes están liderando el camino en términos de expansión relativa. Un panorama que una vez fue dominado por grandes bancos y compañías de tarjetas de crédito ahora está siendo atacado por disruptores interesados en capturar una cuota de mercado.

Según un estudio de McKinsey, hay cuatro factores principales en el núcleo de esta transformación:

  • Adopción de pagos cashless inducidos por la pandemia

  • E-commerce

  • Impulso del gobierno a los pagos digitales

  • Fintech

Cabe destacar como la pandemia ha sido una gran catalizadora en el aumento de la inclusión financiera al fomentar medios de pago alternativos y nuevas formas de pedir préstamos y ahorrar. Estos nuevos servicios digitales son, de hecho, más fáciles de acceder y consumir. En América Latina y el Caribe (LAC), la Covid provocó un aumento dramático en los pagos sin efectivo, el 40% de los adultos realizó una compra en línea, el 14% de los cuales lo hizo por primera vez en su vida.

El e-commerce ha visto un crecimiento estelar, con una penetración que probablemente superará el 70% de la población en 2022, los actores nacionales y globales, incluidos Mercado Libre y Falabella, están impulsando la innovación de pagos digitales para proporcionar una experiencia de cliente cada vez más fluida en sus plataformas.

Los bancos centrales están promoviendo nuevas infraestructuras para pagos en tiempo real, con el objetivo de proporcionar una tecnología más económica y rápida para la transferencia de dinero tanto para ciudadanos como para empresas. PIX es probablemente el mayor caso de éxito. Una plataforma de pagos instantáneos desarrollada por el Banco Central do Brasil (Banco Central de Brasil), comenzó a operar en noviembre de 2020 y, en 18 meses, más del 75% de los brasileños adultos lo había utilizado al menos una vez. La red procesa alrededor de $250 mil millones en pagos anualizados, aproximadamente el 20 % del gasto total de los clientes. Los usuarios (incluidos los trabajadores autónomos) pueden enviar y recibir pagos en tiempo real a través de una interfaz sencilla, 24 horas al día, 7 días a la semana y de forma gratuita. Las empresas tienen que pagar una pequeña tasa. En Estados Unidos, la Federal Reserve ha anunciado que lanzará FedNow a mediados de 2023, una red de pagos con características similares a PIX. Estas iniciativas tienen como objetivo resolver problemas como los acuerdos lentos y la baja interoperabilidad entre las partes.

Los bancos establecidos aún poseen la mayor parte del mercado de pagos digitales, sin embargo, las fintech han estado amenazando este dominio, aprovechando su agilidad para actuar rápidamente y satisfacer las necesidades de los clientes de formas más innovadoras y creativas. Sin el lastre de los sistemas legacy, o los modelos comerciales atados a las viejas redes de pago, las fintechs no han dudado en probar y adoptar nuevas tecnologías y sistemas de pago. Su estrategia enfocada a móvil y digital les está ayudando a capturar y retener al segmento más joven del mercado, que exige experiencias integradas en tiempo real con las que pueden interactuar tan sólo pulsando un botón. Un ejemplo es Paggo, una fintech guatemalteca que ayuda a las empresas a agilizar los pagos permitiéndoles compartir un simple código QR que los clientes pueden escanear para transferir dinero.

El panorama de los pagos no solo se ve afectado por fuerzas externas, los cambios que provienen de la industria también están remodelando la experiencia del cliente y habilitando nuevos servicios.

La norma ISO 20022 es un estándar flexible para el intercambio de datos que está siendo adoptado por la mayoría de las instituciones de la industria financiera para estandarizar la forma en que se comunican entre sí, optimizando así la interoperabilidad. Gracias a la adopción de ISO 20022, es más sencillo para los bancos leer y procesar mensajes, lo que se traduce en procesos internos más fluidos y una automatización más sencilla. Para los usuarios finales, esto significa pagos más rápidos y potencialmente más baratos, así como aplicaciones financieras más ricas e integradas.

3DS2 está siendo adoptado por el ecosistema de pagos con tarjeta de crédito y débito. Se trata, esencialmente, de una solución de autenticación de pagos que sirve para transacciones de compras en línea. De manera similar a ISO 20022, el usuario final ni siquiera conocerá la tecnología subyacente, sino que sólo percibirá un pago más fluido y sin fricciones. 3DS2 evita que el usuario sea redirigido a su aplicación bancaria para confirmar la compra de un artículo en línea, ahora todo sucede en el sitio web o la aplicación del vendedor. Todo esto se hace al mismo tiempo que se mejora la detección y prevención de fraude; esta nueva solución dificulta el uso de la tarjeta de crédito o débito sin autorización. El beneficio de la adopción de 3DS2 es doble: por un lado, el usuario tiene mayor confianza, por otro, los comerciantes están más contentos debido a una menor tasa de abandono de clientes; de hecho, el miedo al fraude en el proceso de pago suele ser una de las principales razones para abandonar una compra en línea. Esta solución es especialmente ventajosa para la región de LAC, donde, a pesar de la amplia adopción del comercio electrónico, las personas aún se muestran reacias a realizar transacciones online. Uno de los factores que contribuyen a esta incongruencia es el miedo al fraude. Cybersource informó que en 2019, una quinta parte de las transacciones de comercio electrónico se marcaron como potencialmente fraudulentas y el 20 % se bloquearon, es decir, más de 6 veces el promedio mundial. Es evidente que la adopción de 3DS2 por parte de las plataformas fomentará la confianza de los compradores online.

Vale la pena mencionar también el papel que juegan la blockchain y las criptomonedas. Redes como Ethereum o Lightning son una alternativa descentralizada a las redes de pago más tradicionales. En los últimos años, más y más personas han comenzado a utilizar esta tecnología debido a sus características únicas: tarifas bajas, tiempo de procesamiento rápido y alcance global. América Latina ha visto una explosión en la adopción debido a varios factores, siendo muy prominentes las remesas y los pagos en stablecoins. Los proveedores de servicios de remesas tradicionales son, de hecho, más lentos y más caros que las redes de blockchain. Especialmente en Argentina, un número cada vez mayor de trabajadores autónomos exigen que se les pague en USDC o USDT, dos stablecoins vinculadas al valor del dólar, para así poder protegerse de la inflación.

Está claro que el panorama de los pagos está evolucionando rápidamente, por un lado, los clientes esperan productos y servicios que se integren a la perfección con todos los aspectos de sus vidas digitales. Cada vez que una aplicación se percibe como lenta, mal diseñada o simplemente le faltan algunas funciones, el usuario puede cambiar fácilmente a la alternativa de un competidor. Por otro lado, la cantidad de actores que compiten por su participación en el mercado de pagos digitales está en auge, lo que reduce los márgenes de los productos tradicionales. La única forma de navegar con éxito en este entorno complejo es invertir en innovación y en la creación de nuevos modelos de negocio. No existe un planteamiento único para enfrentarse a tales desafíos, pero no hay duda de que toda empresa con éxito necesita aprovechar el poder de los datos y la tecnología para proporcionar a sus clientes la experiencia personalizada y en tiempo real que exigen. En MongoDB creemos que una base sólida para lograrlo está representada por una developer data platform altamente flexible y escalable, que permite a las empresas innovar más rápido y monetizar mejor sus datos de pago.

¡Visite la web de Servicios Financieros de MongoDB para obtener más información!

← Previous

How Much is Your Data Model Costing Your Business?

Economic volatility is creating an unpredictable business climate, forcing organizations to stretch their dollars further and do more with less. Investments are under the microscope, and managers are looking to wring every ounce of productivity out of existing resources. IT spend is a concern and many IT decision-makers aren't sure what's driving costs. Is it overprovisioning? Cloud sprawl? Shadow IT? One area that doesn't get a lot of attention is how the data is modeled in the database. That's unfortunate because data modeling can have a major impact in terms of the cost of database operations, the instance size necessary to handle workloads, and the work required to develop and maintain applications. This post is also available in: 简体中文 Pareto patterns Data access patterns are often an illustration of the Pareto Principle at work, where the majority of effects are driven by a minority of causes. Modern OLTP applications tend to work with data in small chunks. The vast majority of data access patterns (the way applications access and use data) work with either a single row of data or a range of rows from a single table. At least that's what we found at Amazon , looking at 10,000 services across all the various RDBMS based services we deployed. Normalized data models are quite efficient for these simple single table queries, but the less frequent complex patterns require the database to join tables to produce a result, exposing RDBMS inefficiencies. The high time complexity associated with these queries meant significantly more infrastructure was required to support them. The relational database hides much of this overhead behind the scenes. When you send a query to a relational database, you don't actually see all the connections opening up on all the tables, or all the objects merging. Even though 90% of the access patterns at Amazon were for simple things, the 10% that were doing more complex things were burning through CPU to the point that my team estimated they were driving ~50% of infrastructure cost. This is where NoSQL data modeling can be a game-changer. NoSQL data models are designed to eliminate expensive joins, reduce CPU utilization, and save on compute costs. Modeling for efficiency in NoSQL There are two fundamental approaches to modeling relational data in NoSQL databases: Embedded Document - All related data is stored in a single rich document which can be efficiently retrieved when needed. Single Collection - Related data is split out into multiple documents to efficiently support access patterns that require subsets of a larger relational structure. Related documents are stored in a common collection and contain attributes that can be indexed to support queries for various groupings of related documents. The key to building an efficient NoSQL data model and reducing compute costs is using the workload to influence the choice of data model. For example, a read-heavy workload like a product catalog that runs queries like, "get all the data for a product" or "get all the products in a category," will benefit from an embedded document model because it avoids overhead of reading multiple documents. On the other hand, a write-heavy workload where writes are updating bits and pieces of a larger relational structure would run more efficiently with smaller documents stored in a single collection which can be accessed independently and indexed to support efficient retrieval when all the data is needed. The final choice depends on the frequency and nature of the write patterns and whether or not there's a high velocity read pattern that's operating concurrently. If your workload is read-intensive, you want to get as much as you can in one read. For a write-intensive workload, you don't want to have to rewrite the full document every time it changes. Joins increase time complexity. In NoSQL databases, depending on the access pattern mix, all the rows from the relational tables are stored either in a single embedded document or as multiple documents in one collection that are linked together by indexes. Storing multiple related documents in a common collection means there is no need for joins. As long as you're indexing on a common dimension across documents, you can query for related documents very efficiently. Now imagine a query that joins three tables in a relational database and your machine needs to do 1,000 of them. You would need to read at least 3,000 objects from multiple tables in order to satisfy the 1,000 queries. With the document model, by embedding all the related data in one document, the query would read only 1,000 objects from a single collection. Machine wise, having to merge 3,000 objects from three tables versus reading 1,000 from one collection will require a more powerful and expensive instance. With relational databases, you don't have as much control. Some queries may result in a lot of joins, resulting in higher time complexity which translates directly into more infrastructure required to support the workload. Mitigate what matters In a NoSQL database, you want to model data for the highest efficiency where it hurts the most in terms of cost. Analytical queries tend to be low frequency. It doesn't matter as much if they come back in 100 ms or 10 ms. You just want to get an answer. For things that run once an hour, once a day, or once a week, it's okay if they're not as efficient as they might be in a normalized relational database. Transactional workloads that are running thousands of transactions a second need to process as efficiently as possible because the potential savings are far greater. Some users try to practice these data modeling techniques to increase efficiency in RDBMS platforms since most now support document structures similar to MongoDB. This might work for a small subset of workloads. But columnar storage is designed for relatively small rows that are the same size. They do work well for small documents, but when you start to increase the size of the row in a relational database, it requires off-row storage. In Postgres this is called TOAST (The Oversized-Attribute Storage Technique). This circumvents the size limit by putting the data in two places, but it also decreases performance in the process. The row based storage engines used by modern RDBMS platforms were not designed for large documents, and there is no way to configure them to store large documents efficiently. Drawing out the relationship The first step we recommend when modeling data is to characterize the workload by asking a few key questions: What is the nature of the workload? What is the entity relationship diagram (ERD)? What are the access patterns? What is the velocity of each pattern? Where are the most important queries that we need to optimize? Identifying the entities and their relationships to each other is going to form the basis of our data model. Once this is done we can begin to distill the access patterns. If it's a read heavy workload like the product catalog you'll most likely be working with large objects, which is fine. There are plenty of use cases for that. However, if you're working with more complex access patterns where you're accessing or updating small pieces of a larger relational structure independently, you will want the data separated into smaller documents so you can efficiently execute those high velocity updates. We teach many of these techniques in our MongoDB University course, M320: MongoDB Data Modeling . Working with indexes Using indexes for high-frequency patterns will give you the best performance. Without an index, you have to read every document in the collection and examine it to determine which documents match the query conditions. An index is a B-tree structure that can be parsed quickly to identify documents that match conditions on the indexed attributes specified by the query. You may choose to not index uncommon patterns for various reasons. All indexes incur cost as they must be updated whenever a document is changed. You might have a high velocity write pattern that runs consistently and a low velocity read that happens at the end of the day, in which case you'll accept the higher cost of the full collection scan for the read query rather than incur the cost of updating the index on every write. If you are writing to a collection 1,000 times a second and reading once a day, the last thing you want to do is add an index update for every single write just to make the read efficient. Again, it depends on the workload. Indexes in general should be created for high-velocity patterns, and your most frequent access patterns should be covered by indexes to some extent, either partially or fully. Remember that an index still incurs cost even if you don't read it very much or at all. Always make sure when you define an index that there is a good reason for it, and that good reason should be that you have a high frequency access pattern that needs to use it to be able to read the data efficiently. Data modeling and developer productivity Even after you've optimized your data model, cost savings will continue to accrue downstream as developers find that they can develop, iterate, and maintain systems far more efficiently than in a relational database. Specific document design patterns and characteristics of NoSQL can reduce maintenance overhead and in many cases eliminate maintenance tasks altogether. For example, document databases like MongoDB support flexible schema which eliminates the need for maintenance windows related to schema migrations and refactoring of a catalog as with RDBMS. A schema change in a relational database almost always impacts ORM data adapters that would need to be refactored to accommodate the change. That's a significant amount of code maintenance for developers. With a NoSQL database like MongoDB, there's no need for cumbersome and fragile ORM abstraction layers. Developers can store object data in its native form instead of having to normalize it for a tabular model. Updating data objects in MongoDB requires almost zero maintenance. The application just needs to be aware documents may have new properties, and how to update them to the current schema version if they don’t. MongoDB will lower license fees and infrastructure costs significantly, but possibly the biggest savings organizations experience from moving away from RDBMS will come from reduced development costs. Not only is there less code overall to maintain, but the application will also be easier to understand for someone who didn't write the code. MongoDB makes migrations far simpler and less prone to failure and downtime. Applications can be updated more frequently, in an easier fashion, and without stressing about whether a schema update will fail and require a rollback. Overall, maintaining applications over their lifetime is far easier with NoSQL databases like MongoDB. These efficiencies add up to significant savings over time. It's also worth mentioning that a lot of up-and-coming developers see relational databases as legacy technology and not technology they prefer to use. With MongoDB it is easier to attract top talent, a critical factor in any organization's ability to develop best-of-breed products and accelerate time-to-value. Uplevel your NoSQL data modeling skills If you want to start reining in the hidden costs in your software development lifecycle by learning how to model data, MongoDB University offers a special course, M320: MongoDB Data Modeling . There are also dozens of other free courses, self-paced video lessons, on-demand labs, and certifications with digital badges to help you master all aspects of developing with MongoDB.

March 15, 2023
Next →

MongoDB and Partners: Building the AI Future, Together

If you’re like me, over the past year you’ve closely watched AI’s developments—and the world’s reactions to them. From infectious excitement about AI’s capabilities, to impatience with its cost and return on investment, every day has been filled with AI twists and turns. It’s been quite the roller coaster. During the ride, from time to time I’ve wondered where AI falls on the Gartner hype cycle, which gives "a view of how a technology or application will evolve over time." Have we hit the "peak of inflated expectations" only to fall into the "trough of disillusionment?" Or is the hype cycle an imperfect guide, as The Economist argues? The reality is that it takes time for any new technology—even transformative ones like AI—to take hold. And every advance, no matter how big, has had its detractors. A famous example is that of Picasso (!), who in 1968 said, “Computers are useless. They can only give you answers.” (!!) For our part, MongoDB is convinced that AI is a once-in-a-generation technology that will enhance every future application—a belief that has been reinforced by the incredible work our partners have shared at MongoDB’s 2024 events. Speeding AI development MongoDB is committed to helping organizations of all sizes succeed with AI, and one way we’re doing that is by collaborating with the MongoDB partner ecosystem to create powerful, user-friendly AI development tools and solutions. For example, Fireworks.ai —which is a member of the MongoDB AI Applications Program ecosystem —created an inference solution that hosts gen AI models and supports containerized deployments. This tool makes it easier for developers to build and deploy powerful applications with a range of easy-to-use tools and customization options. They can choose to use state-of-the-art, open-source language, image, and multimodal foundation models off the shelf, or they can customize and fine-tune models to their needs. Jointly, Fireworks.ai and MongoDB provide a solution for developers who want to leverage highly curated and optimized open-source models and combine these with their organization’s own proprietary data—and to do so with unparalleled speed and security. “MongoDB is one of the most sophisticated database providers, and it’s very easy to use,” said Benny Chen , cofounder of Fireworks.ai. "We want developers to be able to use these tools, and we want to work with providers who enable and empower developers." Nomic , another MAAP ecosystem member, also enables developers with best-in-class solutions across the entire unstructured data workflow. Their Embed offering, available through the Nomic API , allows users to vectorize large-scale datasets for use in text, image, and multimodal retrieval applications, including retrieval-augmented generation (RAG), using only their web browser. The Nomic-MongoDB solution is a highly efficient, open-weight model that developers can use to visualize the unstructured datasets they store in MongoDB Atlas . These insights help users quickly discover trends and articulate data-driven value propositions. Nomic also supported the recently announced vector quantization in MongoDB Atlas Vector Search , which reduces vector sizes while preserving performance. Last—but hardly least!—there’s our new reference architecture with MAAP partners AWS and Anthropic. Announced at MongoDB.local London , the reference architecture supports building memory-enhanced AI agents, and is designed to streamline complex processes and develop smarter, more responsive applications. For more—including a link to the code on Github— check out the MongoDB Developer Center . Making AI work for anyone and everyone The companies MongoDB partners with aren’t just making gen AI easier for developers—they’re building tools for everyone. For example, Capgemini has invested $2 billion in gen AI and is training 100,000 of its employees in the technology. GenYoda, a solution that helps insurance professionals with their daily work, is a product of this investment. GenYoda leverages MongoDB Atlas Vector Search to analyze large amounts of customer data, like policy statements, premiums, claims history, and health information. Using GenYoda, insurance professionals can quickly analyze underwriters’ reports to make informed decisions, create longitudinal health summaries, and streamline customer interactions to improve contact center efficiency. GenYoda can ingest 100,000 documents in just a few hours and respond to users’ queries in two to three seconds—a metric on par with the most widely used gen AI models. And it produces results: in one example, by using Capgemini’s solution an insurer was able to increase productivity by 15%, add new reports 25% faster (thus speeding decision-making), and reduce the manual effort of searching PDFs, increasing efficiency by 10%. Building the future of AI together So, what’s next? Honestly, I’m as curious as you are. But I’m also incredibly excited. At MongoDB, we’re active participants in the AI revolution, working to embrace the possibilities that lie ahead. The future of gen AI is bright, and I can’t wait to see what we’ll build together. To learn more about how MongoDB can accelerate your AI journey, explore the MongoDB AI Applications Program .

November 4, 2024