Extending the Service Mesh into a Compliance Enforcement Fabric: A Policy-Aware Architecture for Regulated Financial Platforms
DOI:
https://doi.org/10.15662/IJEETR.2023.0503012Keywords:
Policy-aware service mesh, Zero Trust, event governance, regulated financial platforms, compliance-native architecture, runtime policy enforcement, cryptographic auditabilityAbstract
Regulated financial platforms increasingly depend on microservices, event-driven workflows, partner APIs, and issuer integrations in which a single service interaction can cross regulatory, data-sensitivity, partner, issuer, or payment-security boundaries. Conventional service meshes secure these interactions at the network layer through mutual TLS, workload identity, traffic routing, and observability, and recent Zero Trust research has strengthened identity-centric authorization in cloud-native systems. These approaches, however, remain network-aware rather than compliance-aware: they do not natively reason about data classification, regulatory domain, partner contract scope, or event payload content, so compliance logic is duplicated across services and audit evidence is reconstructed after the fact. This paper proposes a policy-aware service mesh that extends the mesh from a traffic-management layer into a compliance enforcement fabric. The architecture spans data, control, governance, and event planes and externalizes policy decisions from business logic, so that every synchronous request and asynchronous event is evaluated against identity, data-domain, jurisdiction, and purpose-of-access attributes before execution. Each decision can allow, deny, mask, transform, reroute, or escalate an interaction to human approval, and every outcome is bound to a policy version and recorded in a cryptographic audit ledger. Using a co-branded credit card platform as the reference domain, the paper illustrates how partner gateways, issuer adapters, rewards services, and AI-assisted operational tools interact under Zero Trust, least-privilege, and data-minimization constraints. It further defines an evaluation framework covering enforcement latency, authorization consistency, event governance coverage, data leakage prevention, and audit reconstruction time, and discusses key tradeoffs including policy evaluation overhead, sidecar versus ambient deployment, and event schema evolution.
References
[1] N. Dragoni, S. Giallorenzo, A. Lluch Lafuente, M. Mazzara, F. Montesi, R. Mustafin, and L. Safina, “Microservices: Yesterday, today, and tomorrow,” in Present and Ulterior Software Engineering, M. Mazzara and B. Meyer, Eds. Cham, Switzerland: Springer, 2017, pp. 195–216, doi: 10.1007/978-3-319-67425-4_12.
[2] P. Jamshidi, C. Pahl, N. C. Mendonça, J. Lewis, and S. Tilkov, “Microservices: The journey so far and challenges ahead,” IEEE Software, vol. 35, no. 3, pp. 24–35, 2018, doi: 10.1109/MS.2018.2141039.
[3] T. Butler and L. O’Brien, “Understanding RegTech for digital regulatory compliance,” in Disrupting Finance: FinTech and Strategy in the 21st Century, T. Lynn, J. G. Mooney, P. Rosati, and M. Cummins, Eds. Cham, Switzerland: Palgrave Macmillan, 2019, pp. 85–102, doi: 10.1007/978-3-030-02330-0_6.
[4] I. Anagnostopoulos, “Fintech and regtech: Impact on regulators and banks,” Journal of Economics and Business, vol. 100, pp. 7–25, 2018, doi: 10.1016/j.jeconbus.2018.07.003.
[5] National Institute of Standards and Technology, “Artificial intelligence risk management framework (AI RMF 1.0),” NIST AI 100-1, 2023, doi: 10.6028/NIST.AI.100-1.
[6] W. Li, Y. Lemieux, J. Gao, Z. Zhao, and Y. Han, “Service mesh: Challenges, state of the art, and future research opportunities,” in Proc. IEEE Int. Conf. Service-Oriented System Engineering (SOSE), 2019, pp. 122–1225, doi: 10.1109/SOSE.2019.00026.
[7] R. Chandramouli, Z. Butcher, and A. Chetal, “Attribute-based access control for microservices-based applications using a service mesh,” National Institute of Standards and Technology, NIST Special Publication 800-204B, 2021, doi: 10.6028/NIST.SP.800-204B.
[8] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, “Zero trust architecture,” National Institute of Standards and Technology, NIST Special Publication 800-207, 2020, doi: 10.6028/NIST.SP.800-207.
[9] C. Buck, C. Olenberger, A. Schweizer, F. Völter, and T. Eymann, “Never trust, always verify: A multivocal literature review on current knowledge and research gaps of zero-trust,” Computers & Security, vol. 110, Art. no. 102436, 2021, doi: 10.1016/j.cose.2021.102436.
[10] N. F. Syed, S. W. Shah, A. Shaghaghi, A. Anwar, Z. Baig, and R. Doss, “Zero trust architecture (ZTA): A comprehensive survey,” IEEE Access, vol. 10, pp. 57143–57179, 2022, doi: 10.1109/ACCESS.2022.3174679.
[11] A. Pereira-Vale, E. B. Fernandez, R. Monge, H. Astudillo, and G. Márquez, “Security in microservice-based systems: A multivocal literature review,” Computers & Security, vol. 103, Art. no. 102200, 2021, doi: 10.1016/j.cose.2021.102200.
[12] A. Hannousse and S. Yahiouche, “Securing microservices and microservice architectures: A systematic mapping study,” Computer Science Review, vol. 41, Art. no. 100415, 2021, doi: 10.1016/j.cosrev.2021.100415.
[13] M. Fowler, “Event sourcing,” martinfowler.com, 2005.
[14] B. Schneier and J. Kelsey, “Secure audit logs to support computer forensics,” ACM Transactions on Information and System Security, vol. 2, no. 2, pp. 159–176, 1999, doi: 10.1145/317087.317089.
[15] M. Overeem, M. Spoor, and S. Jansen, “An empirical characterization of event sourced systems and their schema changes: Lessons from industry,” Journal of Systems and Software, vol. 178, Art. no. 110970, 2021, doi: 10.1016/j.jss.2021.110970.
